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.
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:
Android users encounter similar messages:
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 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.
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.
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:
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.
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.
Here are a few best practices for connectors:
Apple Push Notification service (APNs):
Managed Google Play:
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:
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.
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.
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.
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:
This table describes how conflicts are resolved.
Some additional items to keep in mind:
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.
For further resources on this subject, please see the links below.
Let us know if you have any additional questions by replying to this post or reaching out to @IntuneSuppTeam on Twitter.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.