That log line is a Microsoft Intune Management Extension (IME) failure: the agent tried to read Azure AD (now Entra ID) sign-in or device information from its local cache through the CMG (Cloud Management Gateway) communication path and the read or lookup returned nothing usable. Error 0x87d00231 is a Configuration Manager/Intune client error meaning a required object was not found, and the trailing “status code 0 statustext” is the empty status text that accompanies it. In plain terms, the agent asked for identity data, got an empty answer, and logged the miss rather than a crash.
This failure usually sits in the workload handoff between Configuration Manager and Intune. The IME is the same agent that runs PowerShell scripts, Win32 app installs, and remediation on co-managed Windows devices. Before it can act on a user- or device-targeted policy, it needs a valid AAD token and device identity context. When that context is missing, stale, or unreachable, the lookup fails and you see 0x87d00231.
The single most useful thing to understand is that this error is a symptom of a missing dependency, not a corrupted component. The agent is reporting an absence. Your job is to find what is absent: a token, a certificate, a cached record, or a network path.
How the AAD info lookup actually fails
The Intune Management Extension does not talk to Entra ID directly for every operation. It relies on the Configuration Manager client and the device’s enrollment state to supply identity. On a co-managed device, the CM client handles the device record and the IME consumes the resulting token and AAD device ID. The CMG is the reverse-proxy endpoint the client uses when it is off the corporate network.
The sequence is roughly: the client authenticates to the CMG over TLS, presents its client certificate, the CMG forwards the request to the site system, and the site returns policy and identity metadata. The IME then reads the cached AAD info to decide which policies apply. If any link returns an empty object, the read yields nothing and the error is logged.
Error 0x87d00231 maps to a “not found” class of failure in the ConfigMgr client error space. The agent expected an object in its local store, such as an AAD user token, a device registration record, or a policy assignment, and the store returned null. The “status code 0” is the HTTP-level status, which is why it looks contradictory: a zero status usually means success, but here it means no status text was attached to a lookup that failed at the object layer.
That contradiction is the counterintuitive detail worth holding onto. Status code 0 does not mean the operation succeeded. It means the transport layer had nothing to report because the failure happened above it, in object resolution. Technicians who chase HTTP errors waste time; the real fault is a missing cached object or an unauthenticated identity context.
What the numbers and thresholds tell you
The error code itself is a 32-bit HRESULT-style value. 0x87d00231 falls in the 0x87d0xxxx range that Configuration Manager reserves for client-side operational errors. The high bit being set marks it as a failure. The specific low-order value distinguishes “object not found” from related failures such as access denied or timeout, which helps you rule out permission and connectivity causes early.
Token lifetimes matter here. Entra ID access tokens typically live about 60 to 90 minutes, and refresh tokens are used to renew them silently. If the device has been offline longer than the refresh window, or if the primary refresh token is invalid, the IME cannot obtain fresh AAD info and the lookup fails. A device that has not checked in for several hours or days is a common candidate.
The CMG has its own timeout behavior. Requests that cannot reach the site system within the configured connection timeout fail and can surface as identity-read failures downstream. Default CMG and client communication timeouts are measured in minutes, not seconds, so a device on a flaky connection may log this error intermittently rather than constantly.
Certificate validity is another hard threshold. The CMG server certificate and the client authentication certificate each have defined validity windows. An expired client certificate, or one whose issuing chain is not trusted, will break the TLS handshake before any identity lookup happens, and the resulting logged error can cascade into the AAD info failure. Check expiry dates against the current date rather than assuming.
Plain-language version: the numbers mostly define windows of time and trust. If the token is too old, the certificate is expired, or the request times out, the identity read comes back empty.
Edge cases that produce this error
Co-management workload sliders are a frequent source. If the device is co-managed but the relevant workload still points to Configuration Manager while the IME expects Intune data, the identity context can mismatch and the read fails. The error appears when the two management authorities disagree about who owns the device record.
Hybrid Entra join adds another layer. Devices that are hybrid-joined depend on both on-premises AD and Entra ID, and a broken sync or a stale device object in Entra ID can leave the IME without a valid AAD device ID. The lookup then returns nothing even though the device appears healthy in the console.
Freshly imaged or reimaged devices are a classic edge case. The enrollment may not have completed, or the IME started before the device record propagated to Entra ID. Propagation delays are real and are measured in minutes to hours depending on tenant size and sync cadence.
Proxy and TLS inspection appliances can also cause this. If the CMG traffic is intercepted and the certificate chain is rewritten, the client may fail identity validation while still establishing a nominal connection. The error then looks like a missing object rather than a trust problem.
Red-flag warnings: Do not delete and re-enroll the device as a first step; you will lose logs that identify the root cause. Do not assume the CMG is down just because this error appears; the CMG may be forwarding fine while the object lookup fails. Do not ignore certificate expiry dates; an expired client cert produces misleading downstream errors. Do not treat “status code 0” as success; it is an empty status on a failed object read.
Misconceptions worth correcting
The most common misconception is that this is a CMG outage. In most cases the CMG is healthy and the failure is a missing cached identity object on the client. Checking CMG health first is reasonable, but do not stop there if the CMG reports normal.
A second misconception is that the error is fatal. It is usually a transient lookup miss that resolves after a successful policy refresh or a token renewal. Persistence across reboots and multiple check-in cycles is what separates a transient miss from a real configuration fault.
A third misconception is that status code 0 means the request never left the device. The request may have completed at the transport layer while the object resolution failed. The status text being empty reflects that the failure had no accompanying message, not that nothing happened.
A fourth is conflating this with enrollment failures. Enrollment errors have their own codes. This error occurs after enrollment, during the operational phase when the IME is trying to apply policy. That distinction narrows where to look.
Practical actions and thresholds
Work through these in order and stop when the error clears.
Confirm the device’s enrollment and co-management state. Verify the workload sliders and that the device shows as co-managed with the expected authority. A mismatch here explains a large share of cases.
Check certificate validity. Compare the CMG server certificate and the client authentication certificate expiry dates against today. Renew anything expiring within the next 30 days before it becomes an outage.
Force a policy refresh and token renewal. Trigger a machine policy retrieval cycle and let the device check in. If the error is a stale token or a propagation delay, one or two successful cycles typically clear it.
Review the IME and CM client logs. Look for the sequence around the error, not just the error line. The preceding lines usually name the object that was not found.
Verify network path and TLS trust. Confirm the device can reach the CMG endpoint and that no inspection appliance is rewriting the certificate chain. Test from the device itself, not from your workstation.
Reconcile the two thresholds explicitly. If the device has been offline longer than the token refresh window and the certificate is near expiry, treat both as causes and fix both. Fixing one while the other remains will reproduce the error.
Threshold summary in one place: token refresh window is on the order of an hour or two, propagation delays are minutes to hours, and certificate renewal should start at least 30 days before expiry. When these disagree, the shortest window governs your action.
Comparison of related error paths
| Error or condition | Typical meaning | First check |
|---|---|---|
| 0x87d00231 | Required object not found in local store | Cached AAD info and enrollment state |
| Access denied class | Permission or token scope problem | Role assignments and token validity |
| Timeout class | CMG or network path unreachable | Connectivity and CMG health |
| Certificate trust failure | TLS chain not trusted | Client and server cert chains |
| Enrollment error | Device not properly enrolled | Enrollment records and sync |
| Status code 0 with empty text | Object-layer failure, not transport | Logs around the error line |
The table exists to keep you from misclassifying. Each row points to a different first check, and treating them as interchangeable wastes diagnostic time.
Timeline of a typical failure and recovery
| Stage | What happens | Approximate window |
|---|---|---|
| Device goes offline | Token ages past refresh window | 1 to 2 hours |
| IME attempts lookup | AAD info read returns empty | At next policy cycle |
| Error logged | 0x87d00231 recorded | Immediate |
| Device reconnects | CMG path restored | Minutes |
| Policy refresh | Token and object refreshed | One to two cycles |
| Error clears | Lookup succeeds | Minutes to hours |
| Persistence check | If error remains, config fault | After several cycles |
If the error survives several full cycles and a confirmed healthy network path, stop treating it as transient. At that point you are looking at a configuration or certificate fault that needs deliberate repair.
Limitations and what this error cannot tell you
This log line does not identify which specific object was missing. It tells you the class of failure, not the instance. You need the surrounding log context to name the missing token, record, or policy.
It also does not distinguish a client-side cache problem from a server-side record problem by itself. Both produce the same symptom. Correlating client logs with the console view of the device is what separates them.
Finally, behavior varies by client version and tenant configuration. The mechanisms described here are stable across recent releases, but exact timeout values and refresh windows are configurable and should be read from your environment rather than assumed. Where this article gives ranges, treat them as orientation, not as guarantees.
For production systems, confirm current values against Microsoft’s official documentation and your tenant settings. This article is general technical education about how the error mechanism works, not a supported remediation procedure for a specific environment, and it does not replace guidance from Microsoft support or a qualified administrator who can inspect your actual logs and configuration.