Intune Health Status: monitoring Apple certificates, tokens and connectors with Logic Apps
- The problem
- Seven external certificates, tokens and connectors, each expiring on its own schedule, none raising an incident in Intune.
- What I built
- Two Logic Apps recurrences checking all seven against Graph, alerting 30 days ahead with the values and console link.
- What came of it
- Renewals moved from reactive to scheduled; enrollment stopped breaking without warning.
Intune looks self-contained from the console, but device enrollment rests on a set of external dependencies that live outside it: a certificate issued by Apple, tokens from Apple Business Manager, a binding to Managed Google Play, two connectors installed on on-premises servers, and a threat-defence partner.
Every one of them expires or breaks on its own schedule. Intune shows their state in the console, and I believe some of them send a warning near expiry. But a control that depends on someone opening the right blade, or on a mail landing with the right person that month, is a control that fails quietly. I wanted the check to run on its own, with an owner.
APNs certificate: 365 days; miss the window and every iOS device re-enrols by hand.
Apple Business Manager tokens: DEP and VPP; stop syncing and new devices never appear.
Managed Google Play: a binding that quietly lapses.
Two on-premises connectors: Autopilot and certificates; nobody remembers which server.
Mobile Threat Defense: a partner state with no alarm of its own.
What is actually at stake
The consequences are not uniform, and one of them is far worse than the rest.
The Apple MDM push (APNs) certificate is the one to fear. It is valid for 365 days, and once it expires there is a 30-day grace period in which it can still be renewed. Renew inside that window, using the same Apple ID that created it, and nothing is lost.
Miss it and the situation changes completely. Past the grace period the certificate can no longer be renewed: only a new one can be created. And Microsoft is explicit that a replaced certificate, as opposed to a renewed one, requires every iOS and iPadOS device to be re-enrolled. Not a resync: re-enrolled, by hand, one device at a time, with the user present. On a fleet of any size that is weeks of work and a lot of goodwill.
The same trap is set by the Apple ID itself. Renewal requires the account that created the certificate, so if that person has left the organisation, “renew” is no longer available even inside the grace period. The outcome is identical: replace, then re-enroll everything.
The rest fail less spectacularly but just as quietly. A DEP token that stopped syncing means devices ordered through the reseller never appear in Intune, so they arrive at a desk and cannot be set up. A certificate connector that has drifted out of the active state means Wi-Fi and VPN profiles stop issuing certificates, and devices lose network access as their existing ones expire, days later and with no obvious link back to the cause.
Without monitoring, the first signal for any of these is a support ticket, and by then the remediation window has usually closed. That is the gap this closes.
Two cadences: 4 hours and 24 hours
The system is two recurrences in Logic Apps, each running the same five-step pipeline: trigger, app-only OAuth, GET against Microsoft Graph, parse the response into typed variables, evaluate a condition, and send mail only if the condition is true. Silence means healthy.
They run at different speeds because the dependencies do not carry the same urgency:
Every 4 hours: the two connectors whose failure stops work immediately: the Autopilot connector, without which new devices cannot join the domain, and the certificate connector, without which no certificate is issued.
Every 24 hours: the ones that fail with notice: the APNs certificate and the Apple DEP token, both alerted 30 days before expiry; the Apple VPP token and the Managed Google Play binding, alerted when they stop syncing; and the Mobile Threat Defense connector, alerted on partner state.
Thirty days is not arbitrary, and it is not the same thirty days as Apple’s grace period. It is chosen so the alert lands a month before expiry, while renewal is still routine, rather than relying on the grace period as a safety net. The grace period is what you have left after the process has already failed.
It also allows time for the part that actually delays these renewals: finding whoever holds the Apple ID. Renewal requires the account that created the certificate. That is frequently not the person receiving the alert, and occasionally someone who has left. A week is not enough time to establish that and get access.
The recurrences are deliberately not faster than this. Graph throttles, and a monitoring system that trips the throttling limits degrades the service it is supposed to protect.
What each alert carries
The part that took the longest was not the queries. It was making the mail useful to whoever opens it.
An alert that says “the certificate connector has a failure” tells you nothing you can act on. Each notification carries the failing values pulled from the Graph response (expiry date, last sync date, sync status, partner state) plus a direct link to the exact blade in the Intune console, a link to the Microsoft renewal procedure, and, for the two connectors that run on-premises, which server they are installed on.
That last detail is the one people were most grateful for. Those connectors are installed once, years ago, and nobody remembers where. Putting the hostname in the alert removed a twenty-minute search from the start of every incident.
Two traps worth designing around
Anyone building this should know about two failure modes that are easy to introduce and hard to spot afterwards.