Tenant Health, Service Communications & Alerting
Knowing whether the problem is your tenant, your policy, or Microsoft's service is an operational skill. Tenant status, service health, message center and alert rules are how you find out — before users tell you.
“Is it me, or is it Microsoft?”
Before you spend two hours debugging your own policy, check whether the service itself is having a bad day.
Intune tells you three separate things: is the service healthy, is something about to change, and is something in your tenant broken — like an expired certificate. They are three different places, and mixing them up wastes real time.
The Tenant status page
Found under Tenant administration → Tenant status. Microsoft describes the page as divided into three tabs:
| Tab | Tells you |
|---|---|
| Tenant details | Licence counts, service release (ring), MDM authority, tenant name/location |
| Connector status | Health of connectors — Apple MDM push certificate, VPP tokens, Managed Google Play, certificate connectors |
| Service health and message center | Active Intune incidents and advisories, together with Intune-relevant message center posts |
Three tabs, not four
It is easy to assume service health and message center are separate tabs here, because they are separate concepts and separate pages in the Microsoft 365 admin center. On the Intune Tenant status page they share a single tab. Know the concepts apart, and the tab count together.
Connector expiry is the classic real-world outage
The Apple MDM push certificate is valid for 365 days and must be renewed annually. If it expires, every iOS/iPadOS device stops checking in and cannot be managed. There is a 30-day grace period after expiry in which you can still renew.
Two exam-critical details:
- Renew the certificate using the same Apple account you used to create it, so the existing certificate and its topic are preserved. Replacing it with a brand new certificate changes the push topic, and that is what forces re-enrolment of every device. Note the nuance: simply changing the Apple ID associated with the certificate is a documented, supported process — you sign in to the Apple Push Certificates Portal with the new Apple ID, redownload the certificate, and upload it to Intune with that new Apple ID. Losing access to the original account is a serious problem, but the re-enrolment trigger is a new certificate, not the account label.
- Connector status is on the Tenant status page, not the service health dashboard, because an expired certificate is your problem, not a Microsoft outage.
The same logic applies to VPP tokens and the Managed Google Play connection.
Service health vs message center
| Feature | Service health dashboard | Message center |
|---|---|---|
| Answers | Is something broken right now? | What is changing, and when? |
| Content | Incidents and advisories with status updates | Planned changes, new features, deprecations, required actions |
| Timeframe | Now / recent | Upcoming — usually with a deadline |
| Typical action | Wait, communicate to users, track the incident | Plan, test, update documentation before the change lands |
| Found in | Microsoft 365 admin center, and surfaced in Tenant status | Microsoft 365 admin center, and surfaced in Tenant status on the same tab as service health |
If a question describes an admin who was “surprised” by a change, the process failure is not monitoring the message center. If users report a sudden failure with no configuration change, check service health first.
Operational baselines
An operational baseline is simply a documented record of what normal looks like — typical enrolment volume, expected compliance percentage, usual startup time. Without one, you cannot tell a genuine incident from ordinary variation. Endpoint Analytics baselines are the measurable half of this; documented thresholds and owners are the other half.
Alerts and notifications
The blueprint asks you to “configure alerts and notifications for policy and compliance changes, including setting up alert rules for compliance drift, enrolment failures, and configuration conflicts.” Learn that wording — but also learn that Intune does not implement this as one universal alerting engine. Different conditions use different documented mechanisms, and questions are usually really asking which mechanism.
| Condition | Why it matters | The actual mechanism |
|---|---|---|
| Compliance drift | Devices sliding out of compliance erodes Conditional Access protection quietly | Actions for noncompliance on the compliance policy — send an email notification to the user, apply a grace period before marking noncompliant, then escalate (remotely lock, retire) |
| Enrolment failures | New starters cannot get working devices; often a token or certificate problem | Enrolment failure reporting plus connector state on Tenant status |
| Configuration conflicts | Two profiles setting the same value differently — the setting ends in a conflict state and applies neither cleanly | Per-setting status on the profile |
| Cloud PC events | Provisioning, connection or image upload failures on Windows 365 | Cloud PC Alerts — genuine configurable alert rules |
Where configurable alert rules genuinely exist
If a question describes alert rules with severity levels, thresholds and email recipients, the documented home for that in the Intune admin center is Tenant administration → Cloud PC Alerts for Windows 365 Enterprise. There you can set conditions and thresholds, define severity, switch each rule on or off, and choose console and/or email notification. Viewing them requires the Intune Administrator or Windows 365 Administrator role.
For device compliance, the notification path is not an alert rule — it is actions for noncompliance on the compliance policy itself, which is where the email notification, the grace period and the escalation actions are configured.
Getting this distinction right is worth more than memorising the objective’s phrasing: the phrasing tells you the topic, the mechanisms tell you the answer.
Configuration conflicts: what actually happens
When two profiles assigned to the same device set the same setting to different values, the result is a conflict, and the setting is not reliably applied. Intune does not silently pick a winner based on profile name or creation date.
How to resolve, in the order the exam expects:
- Identify the conflicting profiles using the per-setting status report on the profile
- Remove the setting from one profile, or narrow the assignment so both do not target the same device
- Re-check status — conflicts clear once only one profile owns the setting
Note the distinction from compliance: a conflict is a configuration problem. A device can be conflicted and still report compliant, which is exactly why alerting on both matters.
iOS devices across the tenant stop checking in overnight and cannot be managed. No policy or configuration changes were made. Where should you look first?
A configuration setting reports a conflict state on several devices. What is the correct way to resolve it?