Read this post for best practices when you’re using Intune to enroll users, set up certificate and more!

By Carolina de Sa Luz – Program Manager | Microsoft Endpoint Manager – Intune

Microsoft Endpoint Manager lets you manage a wide set of endpoint platforms by configuring and deploying policies and applications to users and devices from the cloud. This blog post describes best practices to enroll users, set up certificates, assign access and permissions, and multiple applications assignments.

We recommend enabling multi-factor authentication (MFA) for both users and administrators.

Note: Users will need a Microsoft Intune license, see Licenses available for Microsoft Intune to determine the best choice for your organization. For administrators an Azure AD license will be needed, see Features and licenses for Azure AD Multi-Factor Authentication.

Common enrollment scenarios

Enrollment failures occur if there’s a misconfiguration during set up by the administrator or the end user didn’t follow the enrollment process correctly.

Here are four common messages that users might see when enrolling an iOS device:

Common error messages users might see when enrolling an iOS device.

\n
• Username not recognized – This message appears when the end user doesn’t have an Intune license assigned. Once you license the user, they should be able to enroll their device. Read about assigning licenses to users here.
\n
• Couldn’t add your device – If you see this message during enrollment, it means that your administrator hasn't yet configured Apple Push Notification Service (APNS). This is a key requirement to manage any Apple device. Once the certificate is set up, the user will be able to set up the device. Read about Apple MDM push certificates here.
\n
• Profile Installation Failed – The user sees this message if the administrator has blocked personal device enrollment under device enrollment restrictions. Learn about setting enrollment restrictions here.
\n
• Update your iOS device – Users see this message when an administrator configures an operating system (OS) version requirement under device enrollment restrictions. For example, if the administrator requires iOS version 14 and the device is using iOS version 13.x or below, users must upgrade their device to complete enrollment.
\n

Android users encounter similar messages:

Common error messages users might see when enrolling an Android device.

\n
• Your company support needs to assign license for access – This means that the user doesn’t have an Intune license. They will be able to enroll their device after you license the user. Read this article to learn about options for enrolling Android devices in Intune.
\n
• Check device settings – Users get this message if you haven’t configured Managed Google Play, which is required to manage Android Enterprise. Once you configure Managed Google Play, users will be able to enroll their Android Enterprise devices.
\n
• Couldn’t add your device – This message refers to enrollment restrictions for Android Enterprise Work Profiles and Work Profile Personal. You might be aware that Google has officially deprecated Device Admin-based management. For that reason, we recommend blocking this mode under Devices > Enrollment restrictions and using Android Enterprise instead.
\n

Intune reports

Microsoft Intune enables you to quickly generate and view a wide variety of reports to monitor configuration, compliance, enrollment, status updates and other information. We developed a new reporting section to make it easier to access these new types of reports, enhance the structure of existing reports, and improve functionality so you can better monitor the health of your devices and apps across the organization.

Check out this blog post to learn more about the reporting framework and read about the latest new reports here. You can get to these reports by navigating to the Microsoft Endpoint Manager admin center > Devices > Monitor and select the report you want to generate.

Enrollment failures

Enrollment failures can happen. The Enrollment failures report lets you monitor activity for all users or for a specific user. The report includes a graphical overview where you can see failed enrollments over time. It can also display alerts.

For example, in the report below, an end user has tried to enroll several iOS and Android devices. The report shows that the user failed to enroll their personal Android device and iOS device. This is likely due to an enrollment restriction.

Example enrollment errors for iOS and Android devices.

Troubleshooting enrollment failures

As an admin, consider which policies are in place that might be preventing the device from enrolling. In this example, the admin has configured a policy to block personal enrollment for Android Enterprise. Additionally, for iOS/iPadOS, the policy has been set with a minimum version requirement of iOS version 14. The iOS devices that failed do not meet this requirement because they are running version 13.7.

Example of a device restriction policy configured to block personal enrollment for Android Enterprise.

If you’re seeing enrollment failures, check your device enrollment restrictions policy. It might be that a conditional access policy has been set up requiring devices to be enrolled in Intune and compliant.

The example also shows that devices can have a range of OS versions, especially iOS devices. For this scenario, the user needs to upgrade their device from version 13.7 to 14.0 to complete the enrollment.

Not all failures are due to policy configurations. An incomplete enrollment can occur for the following reasons:

\n
• A user halts an action during an enrollment.
\n
• They closed the Company Portal during an enrollment.
\n
• They took longer than 30 minutes between each section of the enrollment process.
\n

Example screenshot of the incomplete user enrollment report.

You can learn more in this article about incomplete user enrollment.  We also recommend reading this article on troubleshooting device enrollment for additional help if you’re experiencing issues with device enrollment.

Working with connectors

Connectors are connections that you configure to external services such as Apple Volume Purchase Program (VPP) or certificates or credential required to connect to an external service like Google Play App Sync.

Intune works with companies such as Apple and Google, and you can check the status of third-party relationships in the Microsoft Endpoint Manager admin center. Go to Tenant administration, and then select Tenant Status > Connector status to view details, including license availability and use, communications, and connector status. This article provides more information about the Intune Tenant Status page. Find out about connectors for Intune here.

Example screenshot of Connector status details under the Tenant admin blade.

Here are a few best practices for connectors:

Apple Push Notification service (APNs):

\n
• You need to renew the APNs every 365 days with the same Apple ID you used to create the certificate.
  Important
  You need to renew, not replace, the APNs certificate. If you replace it, you will break every Apple enrollment you have in place.
\n
• Renew the certificate with the Apple ID you used to initially create the certificate.
\n
• Always use an administrative Apple ID. With a personal Apple ID, you run the risk of losing access to an account when someone leaves the organization. If you lose access to an account, we recommend that you reach out to Apple Support Services.
\n

Managed Google Play:

\n
• Use an administrative Gmail account to manage Android Enterprise devices. This account should only be used for this purpose.
\n
• Never disconnect the connection you build with Google. If you do, you will break every enrollment that you have for Android Enterprise in your organization.
\n

Delegating access

Delegating access is used extensively by organizations that operate across multiple geographies. They decentralize IT operations, giving local administrators permissions to manage and report their local devices. Intune gives you the ability to create role-based access control (RBAC) and scope tags to manage delegated access.  With RBAC, you’re setting the administrators’ permissions and the type of users they can work with. With Scope Tags you can mark the objects that the administrators can look at and work with. Read more about RBAC with Intune here.

Troubleshooting a delegated access scenario

When you’re working with scope tags, remember that the default scope tag is automatically added to all untagged objects that support scope tags. For example, say you created an OEMConfig policy. An OEMConfig policy allows administrators to configure unique settings specific to the OEM that developed that device. Find out more about OEMConfig policies and how they work with Intune here.

To configure this type of policy, first you need to add the OEM application. After that you’ll be able to create your policy by attaching the specific application to your policy. Each OEM has their own application. Samsung, for example, has a KSP application. Zebra devices have Zebra OEMConfig applications.

However, after you create the policy, you might get an unauthorized access message when you try to edit it:

Example screenshot on an unauthorized access message when an OEM Config policy automatically inherits the default scope tag.

When you add the OEM Config application, the application will automatically inherit the default scope tag. The OEM Config policy automatically inherits administrator’s scope tag. This mismatch causes the unauthorized access screen message.

Resolution options: Your local administrator can reach out to central administration and ask them to attach the scope tag to your relevant application.

The second option is to get permission to read all the mobile applications that have been added to the environment.

To learn about scope tags for distributed IT with Intune, check out this article.

Deployment and Assignment

When you’re deciding whether to deploy to users or devices, the answer often depends on the circumstances. Understanding who needs the devices and what they will be used for will help you determine if you should deploy a policy or application to a user group or device group.

\n
• Device groups are used for applying applications and policies to a set of devices, regardless of the user.
\n
• User groups are set up with the end user in mind. The user might use multiple devices.
\n

Here’s an example. A global company has a team of sellers that uses Microsoft Dynamics to sell to their customers and seal deals. The administrator must deploy the Dynamics application to the sellers. The best way to deploy the Dynamics application is to the user group to target a set of users rather than specific devices.

The company also has a team of field engineers who work in shifts and use shared ruggedized devices throughout the shifts. In this case, the administrator would use a device group to ensure that all these devices, regardless of who is using them, can receive the correct applications and policies.

Learn how to create groups for users and devices by reading this article and see how to assign user and device profiles for additional tips on deciding when to deploy to a user group vs device group.

Note
When working with assignment groups, it’s important to remember that you can’t add multiple application assignments to devices. However, you can assign users to multiple groups with different intents. If you deploy applications and policies to multiple user groups, take into consideration what will happen if the same user is in both groups:

\n
• Required intent always wins the conflict.
\n
• Available intent works alongside Required intent. As an example, Apple Volume Purchase Program (VPP) apps deployed as Required won’t show as Available in the Company Portal app. For this scenario, customers can deploy the app as Required to group A and as Available to Group B. Both groups have the same users. As a result, the application will be deployed as Required and still show as Available in the Company Portal app.
\n
• Available with or without enrollment can be used when devices only have Intune app protection policies. Users can still see which applications have been recommended by their administrators if they assigned apps using this intent.
\n
• Uninstall intent be used to remove specific applications from devices. This is often used by customers with Android devices, such as customers who wish to use Microsoft Edge instead of Chrome.
\n

This table describes how conflicts are resolved.

Some additional items to keep in mind:

\n
• For iOS, you cannot deploy applications as available to groups of devices. This type of assignment only supported for Android Enterprise fully managed and corporate-owned personally enabled (COPE). Find out more about COPE in this post.
\n
• The app is only displayed as Available if the user logged into the Company Portal as the primary user who enrolled the device and if the app is applicable to the device.
\n
• To configure what happens to managed apps when devices are no longer managed, you can select the intended setting under Uninstall on device removal.
\n
• To configure whether a required iOS/iPadOS app is installed as a removable app by end users, you can select the setting under Install as removable.
\n
• AppleID is required to deploy Apple Store Apps. AppleID is required to deploy user license VPP apps. AppleID is not required to deploy device license VPP apps.
\n

Conclusion

There’s a lot to learn when starting out with Intune. We hope this article helps you succeed as you enroll devices and apply policies. Admins can take advantage of Intune to monitor, report, and troubleshoot their environments. Intune has extensive configuration settings and comprehensive security policies that can be applied on each platform to help you customize to meet your organization’s needs.

More info and feedback

For further resources on this subject, please see the links below.

Enroll iOS/iPadOS devices in Intune in Microsoft Intune  

Enroll Android Enterprise personally-owned work profile devices in Intune  

Microsoft Intune Tenant Status page

Device management capabilities in Microsoft Intune

Use role-based access control (RBAC) and scope tags for distributed IT in Intune

Let us know if you have any additional questions by replying to this post or reaching out to @IntuneSuppTeam on Twitter.

By Carolina de Sa Luz – Program Manager | Microsoft Endpoint Manager – Intune

Microsoft Endpoint Manager lets you manage a wide set of endpoint platforms by configuring and deploying policies and applications to users and devices from the cloud. This blog post describes best practices to enroll users, set up certificates, assign access and permissions, and multiple applications assignments.

We recommend enabling multi-factor authentication (MFA) for both users and administrators.

Note: Users will need a Microsoft Intune license, see Licenses available for Microsoft Intune to determine the best choice for your organization. For administrators an Azure AD license will be needed, see Features and licenses for Azure AD Multi-Factor Authentication.

Common enrollment scenarios

Enrollment failures occur if there’s a misconfiguration during set up by the administrator or the end user didn’t follow the enrollment process correctly.

Here are four common messages that users might see when enrolling an iOS device:

Common error messages users might see when enrolling an iOS device.

\n
• Username not recognized – This message appears when the end user doesn’t have an Intune license assigned. Once you license the user, they should be able to enroll their device. Read about assigning licenses to users here.
\n
• Couldn’t add your device – If you see this message during enrollment, it means that your administrator hasn't yet configured Apple Push Notification Service (APNS). This is a key requirement to manage any Apple device. Once the certificate is set up, the user will be able to set up the device. Read about Apple MDM push certificates here.
\n
• Profile Installation Failed – The user sees this message if the administrator has blocked personal device enrollment under device enrollment restrictions. Learn about setting enrollment restrictions here.
\n
• Update your iOS device – Users see this message when an administrator configures an operating system (OS) version requirement under device enrollment restrictions. For example, if the administrator requires iOS version 14 and the device is using iOS version 13.x or below, users must upgrade their device to complete enrollment.
\n

Android users encounter similar messages:

Common error messages users might see when enrolling an Android device.

\n
• Your company support needs to assign license for access – This means that the user doesn’t have an Intune license. They will be able to enroll their device after you license the user. Read this article to learn about options for enrolling Android devices in Intune.
\n
• Check device settings – Users get this message if you haven’t configured Managed Google Play, which is required to manage Android Enterprise. Once you configure Managed Google Play, users will be able to enroll their Android Enterprise devices.
\n
• Couldn’t add your device – This message refers to enrollment restrictions for Android Enterprise Work Profiles and Work Profile Personal. You might be aware that Google has officially deprecated Device Admin-based management. For that reason, we recommend blocking this mode under Devices > Enrollment restrictions and using Android Enterprise instead.
\n

Intune reports

Microsoft Intune enables you to quickly generate and view a wide variety of reports to monitor configuration, compliance, enrollment, status updates and other information. We developed a new reporting section to make it easier to access these new types of reports, enhance the structure of existing reports, and improve functionality so you can better monitor the health of your devices and apps across the organization.

Check out this blog post to learn more about the reporting framework and read about the latest new reports here. You can get to these reports by navigating to the Microsoft Endpoint Manager admin center > Devices > Monitor and select the report you want to generate.

Enrollment failures

Enrollment failures can happen. The Enrollment failures report lets you monitor activity for all users or for a specific user. The report includes a graphical overview where you can see failed enrollments over time. It can also display alerts.

For example, in the report below, an end user has tried to enroll several iOS and Android devices. The report shows that the user failed to enroll their personal Android device and iOS device. This is likely due to an enrollment restriction.

Example enrollment errors for iOS and Android devices.

Troubleshooting enrollment failures

As an admin, consider which policies are in place that might be preventing the device from enrolling. In this example, the admin has configured a policy to block personal enrollment for Android Enterprise. Additionally, for iOS/iPadOS, the policy has been set with a minimum version requirement of iOS version 14. The iOS devices that failed do not meet this requirement because they are running version 13.7.

Example of a device restriction policy configured to block personal enrollment for Android Enterprise.

If you’re seeing enrollment failures, check your device enrollment restrictions policy. It might be that a conditional access policy has been set up requiring devices to be enrolled in Intune and compliant.

The example also shows that devices can have a range of OS versions, especially iOS devices. For this scenario, the user needs to upgrade their device from version 13.7 to 14.0 to complete the enrollment.

Not all failures are due to policy configurations. An incomplete enrollment can occur for the following reasons:

\n
• A user halts an action during an enrollment.
\n
• They closed the Company Portal during an enrollment.
\n
• They took longer than 30 minutes between each section of the enrollment process.
\n

Example screenshot of the incomplete user enrollment report.

You can learn more in this article about incomplete user enrollment.  We also recommend reading this article on troubleshooting device enrollment for additional help if you’re experiencing issues with device enrollment.

Working with connectors

Connectors are connections that you configure to external services such as Apple Volume Purchase Program (VPP) or certificates or credential required to connect to an external service like Google Play App Sync.

Intune works with companies such as Apple and Google, and you can check the status of third-party relationships in the Microsoft Endpoint Manager admin center. Go to Tenant administration, and then select Tenant Status > Connector status to view details, including license availability and use, communications, and connector status. This article provides more information about the Intune Tenant Status page. Find out about connectors for Intune here.

Example screenshot of Connector status details under the Tenant admin blade.

Here are a few best practices for connectors:

Apple Push Notification service (APNs):

\n
• You need to renew the APNs every 365 days with the same Apple ID you used to create the certificate.
  Important
  You need to renew, not replace, the APNs certificate. If you replace it, you will break every Apple enrollment you have in place.
\n
• Renew the certificate with the Apple ID you used to initially create the certificate.
\n
• Always use an administrative Apple ID. With a personal Apple ID, you run the risk of losing access to an account when someone leaves the organization. If you lose access to an account, we recommend that you reach out to Apple Support Services.
\n

Managed Google Play:

\n
• Use an administrative Gmail account to manage Android Enterprise devices. This account should only be used for this purpose.
\n
• Never disconnect the connection you build with Google. If you do, you will break every enrollment that you have for Android Enterprise in your organization.
\n

Delegating access

Delegating access is used extensively by organizations that operate across multiple geographies. They decentralize IT operations, giving local administrators permissions to manage and report their local devices. Intune gives you the ability to create role-based access control (RBAC) and scope tags to manage delegated access.  With RBAC, you’re setting the administrators’ permissions and the type of users they can work with. With Scope Tags you can mark the objects that the administrators can look at and work with. Read more about RBAC with Intune here.

Troubleshooting a delegated access scenario

When you’re working with scope tags, remember that the default scope tag is automatically added to all untagged objects that support scope tags. For example, say you created an OEMConfig policy. An OEMConfig policy allows administrators to configure unique settings specific to the OEM that developed that device. Find out more about OEMConfig policies and how they work with Intune here.

To configure this type of policy, first you need to add the OEM application. After that you’ll be able to create your policy by attaching the specific application to your policy. Each OEM has their own application. Samsung, for example, has a KSP application. Zebra devices have Zebra OEMConfig applications.

However, after you create the policy, you might get an unauthorized access message when you try to edit it:

Example screenshot on an unauthorized access message when an OEM Config policy automatically inherits the default scope tag.

When you add the OEM Config application, the application will automatically inherit the default scope tag. The OEM Config policy automatically inherits administrator’s scope tag. This mismatch causes the unauthorized access screen message.

Resolution options: Your local administrator can reach out to central administration and ask them to attach the scope tag to your relevant application.

The second option is to get permission to read all the mobile applications that have been added to the environment.

To learn about scope tags for distributed IT with Intune, check out this article.

Deployment and Assignment

When you’re deciding whether to deploy to users or devices, the answer often depends on the circumstances. Understanding who needs the devices and what they will be used for will help you determine if you should deploy a policy or application to a user group or device group.

\n
• Device groups are used for applying applications and policies to a set of devices, regardless of the user.
\n
• User groups are set up with the end user in mind. The user might use multiple devices.
\n

Here’s an example. A global company has a team of sellers that uses Microsoft Dynamics to sell to their customers and seal deals. The administrator must deploy the Dynamics application to the sellers. The best way to deploy the Dynamics application is to the user group to target a set of users rather than specific devices.

The company also has a team of field engineers who work in shifts and use shared ruggedized devices throughout the shifts. In this case, the administrator would use a device group to ensure that all these devices, regardless of who is using them, can receive the correct applications and policies.

Learn how to create groups for users and devices by reading this article and see how to assign user and device profiles for additional tips on deciding when to deploy to a user group vs device group.

Note
When working with assignment groups, it’s important to remember that you can’t add multiple application assignments to devices. However, you can assign users to multiple groups with different intents. If you deploy applications and policies to multiple user groups, take into consideration what will happen if the same user is in both groups:

\n
• Required intent always wins the conflict.
\n
• Available intent works alongside Required intent. As an example, Apple Volume Purchase Program (VPP) apps deployed as Required won’t show as Available in the Company Portal app. For this scenario, customers can deploy the app as Required to group A and as Available to Group B. Both groups have the same users. As a result, the application will be deployed as Required and still show as Available in the Company Portal app.
\n
• Available with or without enrollment can be used when devices only have Intune app protection policies. Users can still see which applications have been recommended by their administrators if they assigned apps using this intent.
\n
• Uninstall intent be used to remove specific applications from devices. This is often used by customers with Android devices, such as customers who wish to use Microsoft Edge instead of Chrome.
\n

This table describes how conflicts are resolved.

Some additional items to keep in mind:

\n
• For iOS, you cannot deploy applications as available to groups of devices. This type of assignment only supported for Android Enterprise fully managed and corporate-owned personally enabled (COPE). Find out more about COPE in this post.
\n
• The app is only displayed as Available if the user logged into the Company Portal as the primary user who enrolled the device and if the app is applicable to the device.
\n
• To configure what happens to managed apps when devices are no longer managed, you can select the intended setting under Uninstall on device removal.
\n
• To configure whether a required iOS/iPadOS app is installed as a removable app by end users, you can select the setting under Install as removable.
\n
• AppleID is required to deploy Apple Store Apps. AppleID is required to deploy user license VPP apps. AppleID is not required to deploy device license VPP apps.
\n

Conclusion

There’s a lot to learn when starting out with Intune. We hope this article helps you succeed as you enroll devices and apply policies. Admins can take advantage of Intune to monitor, report, and troubleshoot their environments. Intune has extensive configuration settings and comprehensive security policies that can be applied on each platform to help you customize to meet your organization’s needs.

More info and feedback

For further resources on this subject, please see the links below.

Enroll iOS/iPadOS devices in Intune in Microsoft Intune  

Enroll Android Enterprise personally-owned work profile devices in Intune  

Microsoft Intune Tenant Status page

Device management capabilities in Microsoft Intune

Use role-based access control (RBAC) and scope tags for distributed IT in Intune

Let us know if you have any additional questions by replying to this post or reaching out to @IntuneSuppTeam on Twitter.

Read this post for best practices when you’re using Intune to enroll users, set up certificate and more!

Hi Marc_Laf, thank you for your question. Per our documentation the VPP token is associated with the Apple ID you used to create it, so you'd have to renew the token with this same Apple ID. 

Hi Brendan Main, thanks for the feedback! We've updated the post to better clarify this scenario.

You mention that the APN needs to be renewed using the same Apple ID as it was generated with but what about VPP token? Can that change?

What about the error \" There isn't a device setup for this account yet\". This is an enrollment with a DEM account, but using the preview of \"Setup with Modern Authentication\" for the enrollment part. I have never seen this error before.

E3 licenses is not the lowest bundle license that can achieve this, 365 business premium