Lesson 26 — Microsoft Entra Monitoring and Health

Learning objectives

After completing this lesson, you should be able to assess and monitor the operational health of Microsoft Entra ID.

• Explain the Microsoft Entra Monitoring and Health experience.
• Understand Microsoft Entra Health and tenant recommendations.
• Monitor sign-in, audit and provisioning activity.
• Verify diagnostic settings and Log Analytics ingestion.
• Detect stale or missing identity telemetry.
• Monitor Microsoft Entra Connect and hybrid identity services.
• Build an operational identity health checklist.

The problem this solves

Identity monitoring depends on several connected services.

If one component fails, dashboards, alerts and investigations may all become incomplete without immediately showing an obvious error.

Monitoring and Health

The Microsoft Entra admin centre groups core operational tools under Entra ID → Monitoring & health.

This area includes activity logs, diagnostic settings, Log Analytics, workbooks, recommendations and other tenant monitoring experiences.

What health means

Tenant health is broader than service availability.

It includes telemetry continuity, secure configuration, authentication performance, synchronisation, provisioning, application access and the ability of administrators to detect change.

Microsoft Entra Health

Microsoft Entra Health provides tenant observability through continuous health monitoring and retrospective reporting.

It is designed to help administrators understand service health and identity-related reliability over time.

Why low-latency monitoring matters

Authentication and access problems affect users quickly.

Operational teams need near-real-time signals for failures, latency, degraded dependencies and unexpected changes.

Recommendations are not automatic proof

A recommendation indicates an improvement opportunity, not a complete understanding of the organisation's design.

Review licensing, dependencies, users, applications, emergency access and operational impact before implementation.

Recommendation ownership

Every accepted recommendation should have an owner, target date, change record and validation step.

Dismissed recommendations should include a documented reason and review cycle.

Service issue or tenant issue?

Service Health helps determine whether a problem is broad and Microsoft-managed.

A healthy service status does not rule out tenant-specific configuration, network, application or synchronisation problems.

Operational communication

Record the incident ID, affected service, start time, known impact and Microsoft updates.

Translate technical status messages into clear user-facing communication.

Baseline normal activity

Health monitoring requires an understanding of normal sign-in volume, application usage, provisioning rates and administrative change.

Without a baseline, teams may mistake routine variation for an outage—or fail to notice a genuine drop.

Trend monitoring

Use Workbooks and KQL to compare current activity with previous hours, days and weeks.

Investigate unexpected spikes, sustained failures and unexplained reductions.

Diagnostic setting checks

• The diagnostic setting still exists.
• The correct log categories are selected.
• The intended Log Analytics workspace is selected.
• The destination remains accessible.
• No unapproved change was made.
• New data appears after testing.

Change monitoring

Diagnostic settings are part of the security monitoring boundary.

Changes should be protected through least privilege, Azure activity monitoring and formal change management.

Freshness is contextual

A small test tenant may legitimately have no sign-ins for several hours.

A large production tenant that normally receives thousands of events should not suddenly become silent.

Use multiple tables

Check SigninLogs, AuditLogs and workload identity tables together.

If every identity table stops at the same time, investigate the export and workspace path before assuming normal inactivity.

Understand ingestion delay

Data is not always available immediately after it is generated.

Alert windows and health thresholds should allow for normal Azure Monitor ingestion latency and tenant activity patterns.

Do not use one fixed threshold everywhere

A five-minute freshness threshold may be useful in a busy tenant but meaningless in a small one.

Build thresholds from observed event frequency and business criticality.

Monitor workspace limits

Azure Monitor records operational issues that occur during ingestion, including conditions associated with workspace limits.

Some ingestion errors can indicate potential data loss and should be treated as health events.

Daily cap risk

If a daily cap is configured and reached, ingestion may stop until the reset period.

Monitor usage trends and alert before the cap becomes an operational blind spot.

Alerts need health checks

An alert that has not fired may mean there was no matching condition.

It may also mean the query failed, the rule was disabled, permissions changed, data stopped or the action group failed.

Test end to end

Periodically generate a controlled event, confirm ingestion, verify query results, trigger a test alert and confirm notification delivery.

Document the result and the expected response time.

Hybrid identity dependencies

• Microsoft Entra Connect server availability.
• Active Directory connectivity.
• DNS and network access.
• Service account permissions.
• Health agent connectivity.
• Database and scheduler health.
• Password writeback and password hash sync.

Do not rely on one server

Document the staging server or recovery design for Microsoft Entra Connect.

Monitor both the active and staging environments and test recovery procedures.

Provisioning checks

• Provisioning job is running.
• Credentials remain valid.
• Target application is reachable.
• Attribute mappings are correct.
• Scoping filters include the intended users.
• Failure counts and quarantine status are reviewed.

Common provisioning failures

• Expired target credentials.
• Duplicate attribute values.
• Missing required attributes.
• Insufficient target permissions.
• Invalid scope or assignment.
• Target API throttling or outage.

Certificate and secret expiry

Application credentials often fail suddenly when they expire.

Track expiry dates before the event and prefer certificates, managed identities or federated identity credentials where appropriate.

Ownership matters

Every enterprise application and app registration should have a documented business and technical owner.

Health alerts are ineffective when nobody knows who can repair the application.

Compromise indicators

• Diagnostic settings changed by an unexpected administrator.
• Monitoring destinations removed without an approved change.
• Alert rules disabled after suspicious activity.
• Workspace permissions changed before telemetry loss.
• Audit activity stops immediately after a privileged change.
• Logging gaps align with attacker activity.

Operational failure indicators

• Daily cap reached.
• Workspace ingestion error.
• Expired connector or application credential.
• Incorrect workspace selected.
• Health agent offline.
• Application or network outage.

Weekly review

• Review active recommendations.
• Check log volume and cost trends.
• Review alert quality and false positives.
• Confirm application and hybrid identity owners.
• Review connector and agent versions.
• Validate emergency access monitoring.

Monthly review

• Test end-to-end telemetry and alerting.
• Review retention and daily cap settings.
• Review dismissed recommendations.
• Test hybrid identity recovery procedures.
• Confirm action group recipients.
• Review monitoring permissions.

Health review checklist

• Are Microsoft service incidents reviewed?
• Are sign-in and audit logs current?
• Are diagnostic settings intact?
• Is Log Analytics ingesting normally?
• Are alert rules enabled and healthy?
• Are action groups delivering?
• Is hybrid synchronisation healthy?
• Are provisioning failures reviewed?
• Are recommendations assigned and tracked?

Security best practices

• Restrict who can change diagnostic settings.
• Alert on changes to monitoring resources.
• Use separate operational and security ownership.
• Monitor emergency access account activity.
• Protect workspaces and action groups with least privilege.
• Document data flow and recovery procedures.
• Test monitoring after every major change.