Lesson 29 — Microsoft Entra Provisioning Logs
Microsoft Entra Provisioning Logs provide object-level evidence of what the provisioning service attempted, why an identity was created, updated, skipped or deleted, and where a provisioning operation failed.
A healthy provisioning agent or a running synchronisation job does not prove that every expected user or group reached the target directory. The answer is often inside the individual provisioning event.
This lesson explains how to locate, filter and interpret Provisioning Logs, follow the provisioning lifecycle, review matching and attribute changes, use correlation information and build a repeatable investigation workflow.
What you will learn
This lesson explains how to use Microsoft Entra Provisioning Logs to trace identity lifecycle activity and diagnose provisioning problems.
Learning objectives
After completing this lesson, you should be able to use Microsoft Entra Provisioning Logs as an operational and investigative tool.
- Explain what Provisioning Logs record.
- Locate and filter provisioning activity.
- Interpret create, update, delete, disable and skip actions.
- Distinguish success, failure and skipped outcomes.
- Review object matching and scope evaluation.
- Analyse modified properties and attribute mappings.
- Use object identifiers and correlation information during investigations.
- Build a repeatable provisioning troubleshooting workflow.
The problem this solves
Provisioning failures are often invisible from the user's perspective. The account simply does not appear, an attribute remains stale or access is not removed.
Provisioning Logs show what the service evaluated and the result of that evaluation, allowing administrators to replace guesswork with evidence.
Provisioning lifecycle
What Provisioning Logs record
Provisioning Logs record activity generated by the Microsoft Entra provisioning service. Depending on the workflow, this can include Cloud Sync, application provisioning, cross-tenant synchronisation and other supported provisioning scenarios.
Each record represents the service's processing of a specific source object and target action.
What they do not prove
A successful provisioning record confirms that the provisioning service completed the recorded operation. It does not automatically prove that every downstream application, licence or user experience is working.
Continue into application, audit and sign-in evidence when the incident extends beyond provisioning.
Core log fields
| Field | Meaning | Investigation value |
|---|---|---|
| Date and time | When the provisioning activity occurred. | Correlate with source changes, tickets and audit events. |
| Identity | The user, group or other object processed. | Confirm the correct source object was evaluated. |
| Source system | Directory or application where the object originated. | Establish the source of authority. |
| Target system | Directory or application receiving the operation. | Confirm where the object was expected to appear. |
| Action | Create, update, delete, disable, restore or another provisioning operation. | Understand the intended lifecycle change. |
| Status | Success, failure, skipped or another recorded result. | Prioritise events requiring investigation. |
| Object identifiers | Source and target IDs associated with the event. | Disambiguate duplicate names and UPNs. |
| Job or configuration | The provisioning job that processed the object. | Identify ownership, scope and configuration context. |
Where to find the logs
Provisioning activity can be opened from Microsoft Entra monitoring and health experiences or from the provisioning workflow itself.
For Cloud Sync, the configuration's logs provide the most direct route to object synchronisation evidence.
Start with a time window
Choose a narrow time range around the source-directory change or expected provisioning cycle.
A precise window reduces noise and makes repeated retries or status changes easier to recognise.
Useful filters
| Filter | Use it when | Example question |
|---|---|---|
| Identity | One user or group is affected. | What happened to this employee? |
| Status | You need all failures or skipped events. | Which objects failed in the last day? |
| Action | You are investigating creates, updates or removals. | Were any delete actions attempted? |
| Job or configuration | Multiple provisioning workflows exist. | Which Cloud Sync job processed this object? |
| Source or target | You need to isolate one system boundary. | Did the object leave Active Directory and reach Entra ID? |
| Date range | A change or incident has a known time. | What occurred after the OU move? |
Success
A successful event means the recorded provisioning action completed without an error.
Review the action and modified properties to confirm that success represents the outcome you expected—not merely a technically successful but incorrect update.
Failure
A failed event means the provisioning service attempted an operation but could not complete it.
The detailed message, error code, target response and remediation guidance are the starting points for diagnosis.
Skipped
A skipped event often means the service deliberately took no target action because the object did not meet scope, assignment, matching or other processing criteria.
Skipped does not necessarily mean broken. It records a decision that must be compared with the intended design.
Outcome comparison
| Outcome | What it tells you | Next step |
|---|---|---|
| Success | The recorded operation completed. | Validate the target object and expected attributes. |
| Failure | The service attempted an operation and received or generated an error. | Read the full details and correct the root cause. |
| Skipped | The service evaluated the object but intentionally performed no target action. | Review scope, assignment, eligibility and matching. |
| Retry or repeated attempts | The service is attempting to recover from a transient or persistent problem. | Check whether the error changes or remains consistent. |
Activity details
Open the individual provisioning event rather than relying only on the summary row.
The detailed view can expose processing steps, source and target information, status reasons, identifiers and remediation context.
Modified properties
Modified properties show which attributes the service attempted to create or change and may display old and new values.
This is essential when the user exists but names, departments, addresses or other identity attributes are wrong or stale.
Reading an individual event
Object matching
Before creating a new target object, the provisioning service can attempt to locate an existing object using configured matching rules and identifiers.
Correct matching joins the source identity to the intended target. Incorrect or incomplete matching can create duplicates or update the wrong object.
Matching questions
- Which source value was used?
- Was the value unique?
- Was an existing target located?
- Did the service create instead of join?
- Are source and target identifiers stable?
- Was a duplicate value detected?
Matching investigation
| Observation | Possible meaning | Validate |
|---|---|---|
| New object created unexpectedly | Existing target did not satisfy the matching rule. | Compare matching attributes on both objects. |
| Duplicate-value error | A supposedly unique value already exists. | Search UPN, mail and proxy-address values. |
| Wrong target updated | Matching data was not unique or source data was incorrect. | Review object IDs and authoritative attributes. |
| Object skipped during match | Eligibility or matching requirements were not satisfied. | Read the processing step and skip reason. |
Scope evaluation
Provisioning begins only when an object qualifies for the configured scope.
Organisational unit placement, group membership, assignments and attribute-based filters can all determine whether an object is processed.
Why scope problems look like outages
The agent can be healthy and the job can be running while one user remains absent.
If the object never qualifies, the platform may be operating exactly as configured.
Scope investigation workflow
Attribute mapping evidence
When a target attribute is missing or incorrect, compare the source value, the mapping or transformation and the value sent to the target.
A successful object-level event can still reveal that a particular property was unchanged, empty or transformed differently than expected.
Attributes worth checking
- User principal name
- Display name
- Given name and surname
- Mail and proxy addresses
- Department and job title
- Manager
- Account enabled state
- Extension attributes
Common provisioning failures
| Failure pattern | Likely cause | First check |
|---|---|---|
| Duplicate UPN or address | The target already contains the value. | Search all target objects, including soft-deleted identities where relevant. |
| Required attribute missing | Source data is incomplete. | Inspect source attributes and mapping requirements. |
| Invalid attribute value | Format, length or character restrictions were violated. | Review the property sent to the target. |
| Permission or authorisation failure | The provisioning identity cannot perform the target action. | Review credentials, roles and target permissions. |
| Agent unavailable | Service, server, network or registration problem. | Review agent status and local services. |
| Object outside scope | OU, group, assignment or attribute filter excludes the object. | Read the skip reason and current source placement. |
| Target service unavailable | Transient endpoint, connectivity or service issue. | Review retry activity and service health. |
Correlation and identifiers
Record the source object ID, target object ID, provisioning job and any correlation information shown in the event.
These values are more reliable than display names when multiple objects have similar identities or names change during the incident.
Build an evidence package
- Exact UTC and local timestamps
- Configuration or job name
- Source and target systems
- Source and target object IDs
- Action and status
- Full error or skip reason
- Modified properties
- Related source-directory change
Provisioning Logs and other evidence
| Log source | Best question | Example |
|---|---|---|
| Provisioning Logs | What did the provisioning service do with this object? | Create, update, skip or failure. |
| Audit Logs | Who changed the configuration or directory object? | Scope, assignment or mapping change. |
| Sign-in Logs | What happened when the user attempted authentication? | Account exists but sign-in fails. |
| Agent and server logs | Could the on-premises agent communicate and process work? | Service stopped or network path failed. |
| Source-directory tools | Was the authoritative object and attribute correct? | User created in the wrong OU. |
On-demand provisioning
Where supported, on-demand provisioning can evaluate an individual object immediately and expose how scope, matching and mappings are processed.
Use it after correcting source data or configuration to verify the object before waiting for a normal cycle.
Do not test only the happy path
Test new, existing, renamed, disabled, moved, excluded and duplicate-prone objects.
Provisioning Logs are most useful when expected outcomes are documented before the test.
Repeatable investigation workflow
Quarantine and repeated failures
Provisioning workflows can enter a protective or degraded state when persistent failures prevent normal processing.
Do not merely restart the job. Identify the recurring error pattern, correct the cause and then verify that successful processing resumes.
Failure-rate thinking
One malformed user is an object problem. Hundreds of identical failures beginning at the same time may indicate configuration, credentials, target availability or agent infrastructure.
Group events by error, time and job to identify the blast radius.
Agent Foskett investigation: “The user never appeared…”
Security indicators
- Unexpected bulk create, update or delete activity.
- Privileged identities newly entering scope.
- Provisioning actions from an unfamiliar job.
- Attribute changes that redirect mail or alter identity ownership.
- Repeated permission failures after a credential or role change.
- Configuration changes immediately before mass failures.
Operational indicators
- Growing failure count for one configuration.
- Many skipped users after an OU or group change.
- Duplicate values across multiple identities.
- Stale attributes despite successful object creation.
- Repeated retries without recovery.
- No recent events for an expected active job.
Daily review checklist
| Review | Question | Evidence |
|---|---|---|
| Failures | Are new errors appearing? | Status filter and error grouping. |
| Skipped objects | Are expected identities being excluded? | Skip reasons and scope comparison. |
| Bulk actions | Are create, update or delete counts unusual? | Action filters and baseline. |
| Attributes | Are important mappings producing correct values? | Modified properties and target samples. |
| Job activity | Are expected configurations producing recent events? | Job filter and latest timestamps. |
| Ownership | Does every unresolved event have an owner? | Incident or service-management record. |
Common mistakes
- Checking only whether the agent is active.
- Reading the summary row but not the detailed event.
- Treating every skipped event as a failure.
- Ignoring source and target object IDs.
- Assuming success means every attribute is correct.
- Restarting provisioning without correcting the root cause.
- Changing scope before recording expected impact.
Best practices
- Use narrow time windows and object filters.
- Record exact identifiers, not only names.
- Compare the result with the intended scope and mapping design.
- Correlate provisioning events with audit and source-directory changes.
- Retain evidence for bulk or security-sensitive operations.
- Test corrected objects individually where supported.
- Baseline normal create, update, skip and failure volumes.
Key takeaways
- Provisioning Logs provide object-level evidence of identity lifecycle processing.
- A running job and healthy agent do not prove that every expected object is synchronising.
- Success, failure and skipped outcomes answer different operational questions.
- The detailed event should be reviewed for processing steps, identifiers, reasons and modified properties.
- Scope evaluation commonly explains why an expected identity never appears.
- Object matching must be investigated when duplicates or incorrect joins occur.
- Modified properties reveal which attributes were created or changed.
- Source and target IDs are more reliable than display names during investigations.
- Provisioning Logs should be correlated with audit, sign-in, agent and source-directory evidence.
- The best troubleshooting workflow corrects the root cause, retests the object and verifies the target result.
Related Agent Foskett resources
Continue learning
Microsoft Entra Provisioning Logs
Microsoft Entra Provisioning Logs record object-level provisioning activity, including scope evaluation, matching, create, update, delete, skipped and failed operations across supported identity provisioning workflows.
Microsoft Entra Academy Lesson 29 — Provisioning Logs
This Agent Foskett lesson explains how to filter and read provisioning activity, inspect modified properties, investigate object matching and scope, diagnose common failures and build a repeatable identity provisioning investigation workflow.
