By Mark Hopper – Program Manager II | Microsoft Endpoint Manager – Intune
Microsoft Intune has the capability to integrate and connect with numerous external services. These connectors can include Microsoft services such as Microsoft Defender for Endpoint, third-party services such as Apple Business Manager, on-premises integrations such as the Certificate Connector for Intune, and many more.
Monitoring the health of an Intune environment is often a common focus for Microsoft Endpoint Manager customers. Today, admins can check their Intune tenant’s connector health using the Tenant Status page in the Microsoft Endpoint Manager admin center. However, many customers have expressed interest in exploring what options are available to proactively notify their teams when an Intune connector is determined to be unhealthy.
This blog will walk through the configuration steps to create an automated cloud flow using Power Automate that will notify a team or an individual when an Intune connector is unhealthy. The walkthrough will use the NDES Certificate Connector as an example, but this same flow logic can be leveraged across all Intune connectors in your environment. If you are not familiar with Power Automate, it’s a “low-code” Microsoft service that can be used to automate repetitive tasks to improve efficiencies for organizations. These automated tasks are called flows.
While the flow outlined in this blog will use email as the example notification method, keep in mind that flexibility and customization is key here. You can implement alternative notification methods that best aligns with your organization’s workflows such as mobile push notifications to the Power Automate app, Microsoft Teams channel posts, or even generating a ticket in your Helpdesk system if it can integrate with Power Automate. You can find a list of services that have published Power Automate connectors here.
Note: The example flow in this blog leverages the HTTP action, which is a premium connection action. For more information on Power Automate licensing, see the docs page here.
Permission |
Graph Endpoints |
Intune Connector |
DeviceManagementConfiguration.Read.All |
ndesConnector androidManagedStoreAccountEnterpriseSettings |
NDES Managed Google Play |
DeviceManagementServiceConfig.Read.All |
applePushNotificationCertificate vppToken depOnboardingSettings windowsAutopilotSettings mobileThreatDefenseConnector |
APNS Certificate VPP Tokens DEP Tokens Autopilot MTD |
That should complete your Azure AD Enterprise App configuration. Next, you will be creating a Power Automate cloud flow that performs the following actions every hour for the NDES connectors in your Intune environment:
Method: GET
URI: https://graph.microsoft.com/beta/deviceManagement/ndesConnectors
Authentication: Active Directory OAuth
Authority: https://login.microsoft.com
Tenant: Directory (tenant) ID from Overview blade in your Azure AD App Registration
Audience: https://graph.microsoft.com
Client ID: Application (client) ID from Overview blade in your Azure AD App Registration
Credential type: Secret
Secret: Secret key value generated while configuring the Azure AD App Registration.
Content: Use the ‘Body’ dynamic content value generated from the previous step.
Schema: You can find the JSON schema by running a test GET request in Graph Explorer, and using the response to generate the schema. For example, run the following query in Graph Explorer: https://graph.microsoft.com/beta/deviceManagement/ndesConnectors.
This should return a JSON response. Copy this JSON response and paste it into Generate from sample in your Parse JSON step. This should generate the following schema, which will allow the flow to use the values in the JSON response such as state and lastConnectionDateTime as Dynamic Values in future steps to check if our connector is healthy. Here is what the JSON schema generated from the response should look like:
{
"type": "object",
"properties": {
"@@odata.context": {
"type": "string"
},
"value": {
"type": "array",
"items": {
"type": "object",
"properties": {
"id": {
"type": "string"
},
"lastConnectionDateTime": {
"type": "string"
},
"state": {
"type": "string"
},
"displayName": {
"type": "string"
}
},
"required": [
"id",
"lastConnectionDateTime",
"state",
"displayName"
]
}
}
}
}
Properties that can be used to determine each connector’s health status can be found in Microsoft’s Graph API documentation for Intune.
For commonly used Intune connectors, here are some health check examples that can be used or built on for the health check Condition step, as well as their Graph URI endpoints for the HTTP step:
Apple Push Notification Certificate
URI: https://graph.microsoft.com/beta/deviceManagement/applePushNotificationCertificate
expirationDateTime is less than addToTime(utcNow(), 61, 'day')
URI: https://graph.microsoft.com/beta/deviceAppManagement/vppTokens
lastSyncStatus is equal to failed
or
state is not equal to valid
URI: https://graph.microsoft.com/beta/deviceManagement/depOnboardingSettings
lastSyncErrorCode is not equal to 0
or
tokenExpirationDateTime is less than addToTime(utcNow(), 61, 'day')
URI: https://graph.microsoft.com/beta/deviceManagement/androidManagedStoreAccountEnterpriseSettings
bindStatus is not equal to boundAndValidated
or
lastAppSyncStatus is not equal to success
URI: https://graph.microsoft.com/beta/deviceManagement/windowsAutopilotSettings
syncStatus is not equal to completed
and
syncStatus is not equal to inProgress
Mobile Threat Defense Connectors
URI: https://graph.microsoft.com/beta/deviceManagement/mobileThreatDefenseConnectors
partnerState is not equal to enabled
and
partnerState is not equal to available
You can create a flow for each individual Intune connector, or you can create parallel branches under your recurrence trigger that check multiple connectors’ health in the same flow.
For example, you may not want to check your Managed Google Play connector in the same flow as your NDES connector. Or, you may want to check your DEP token expiration on a different cadence than your DEP token sync status. Flexibility is key here - use what works best for your organization!
In this blog, we executed Graph API requests using the HTTP action without creating a Graph API custom connector. However, an alternative method could be a Power Automate custom connector for Graph, and configuring the HTTP requests as custom actions to read the Graph Intune connector endpoints. Here are some considerations when deciding which method may work best for your organization:
Without custom connector |
With custom connector |
|
|
More information can be found here: 30DaysMSGraph – Day 12 – Authentication and authorization scenarios.
In the health check step, the first URL should return a 403. The second URL should return a 200.
For these new HTTP steps, you’ll need to configure the next step after them to run even if the HTTP request has failed, for two reasons. For the first URL, a 403 is the response code we are hoping for, but Power Automate will interpret it a failed response and will not move on to the next step by default. For the second URL, we want to ensure we move on to the health check step regardless of the response returned, so that a notification email will be sent out if needed.
Thanks to our Mobility MVP Alexander Vanyurikhin for posting this suggestion on Twitter!
You should now have an understanding of how you can leverage Power Automate and Graph API to proactively notify your team when an Intune connector is in an unhealthy state. Please let us know if you have any additional questions by replying to this post or by reaching out to @Mark_Hopper24 or @IntuneSuppTeam on Twitter.
For further resources on Graph API, Power Automate, and Intune connectors, please see the links below.
Blog Post Updates:
4/19/21: Added steps to check for NDES health evaluation.
5/26/21: Updated the syntax from "or" to "and" for both the Autopilot and Mobile Threat Defense Connectors connector health check examples.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.