Trigger Enhanced Log Collection on macOS 27 with Intune: Tokens, Logs and Fixes

Introduction

macOS 27 lets you start an AppleCare log collection on a supervised Mac from the Intune admin center, with no hands on the device. Until now, getting logs to AppleCare meant physical access or a user willing to follow a manual capture, which is slow when that user is travelling or in another building.

This is Part 2 of my series on WWDC26 for Intune admins. Part 1 covered app control on macOS 27. This part takes one item from Apple’s WWDC26 device management updates, AppleCare log collection, and tests it end to end on a Mac.

In this post:

• What Apple added: two MDM commands, two session types and three status items
• Prerequisites, and how to get a token
• Triggering the collection from Intune
• What the user sees on the Mac, screen by screen
• The device logs for a healthy session
• Troubleshooting, based on a failed session and a rejected token

I ran every test with the test tokens Apple publishes, not with a real AppleCare case. The finding to remember: in Intune, Complete means the Mac accepted the token. It does not mean the logs reached Apple.

What’s New

macOS 27 lets IT start an AppleCare log collection remotely on a supervised Mac, with two new MDM commands and three status items to follow the session. Until now this needed hands on the device, or a user willing to run a manual capture.

The same commands work on supervised devices with iOS 27, iPadOS 27 and tvOS 27. This post covers the trigger on macOS.

Two Session Types

The token decides whether the session is interactive. AppleCare sets the type together with IT when it issues the token.

On a Mac the command is sent on the user channel only, so it is handled in the signed-in user’s session.

Status Items

The session reports its progress through declarative status, which a device management service can subscribe to.

enhanced-logging.status takes one of ten values:

Sources: Apple’s WWDC26 device management updates, Collect logs from Apple devices, and the command and statusschemas in Apple’s device-management repository.

Prerequisites

You need a supervised Mac on macOS 27 with a user signed in, an Intune role that includes the new remote task, and a token.

My test device is a MacBook Air (M2, 2022) on macOS 27, supervised and enrolled through Automated Device Enrollment in the my test tenant.

Step 1: Get The Token

The token comes from AppleCare as part of a support ticket; Intune does not generate it. Apple’s documentation describes the flow like this:

1. Open an AppleCare case for the affected device, or use the one you already have.
2. Ask AppleCare for an enhanced log collection token. AppleCare decides the session type with you, and the token carries it. For a Mac it is always interactive.
3. Keep the token for Step 2 and treat it as a secret. It authorises a diagnostic session on the device.

I did not open an AppleCare case for this post. I used the test tokens Apple publishes in its command schema, which run the same flow on the device. My organization in Apple Business has no AppleCare agreement, and the test token still ran end to end. Apple does not document that.

Everything in this post was tested with test-token-normal. With it the Mac shows “No information will be collected from this device” and uploads a 100 KB mock file.

Step 2: Trigger Enhanced Log Collection from Intune

The trigger is a remote action on the device page, and it takes one input: the token.

1. Sign in to the Microsoft Intune admin center.
2. Go to Devices > macOS and select the Mac.
3. Select Remote actions > Trigger enhanced log collection. Microsoft’s documentation places the action under More (…); in my tenant it sits under Remote actions, next to Cancel enhanced log collection.

• In the dialog Trigger enhanced log collection,, enter the token in the AppleCare token field. The confirm button is greyed out while the field is empty.

• Select Trigger enhanced log collection device.

The dialog says collection starts immediately, but the Mac only receives the command at its next check-in. In my test the time the request was made and the time Mac processed it at was approximately 5 minutes 15 seconds later.

Monitor The Action

On the device’s Overview page, open the Device action status tab and find the Trigger enhanced log collection row.

Microsoft documents four states for this action:

My result did not match that description of Completed. The row showed Complete with Last updated at 1:40:37 PM, the second the Mac acknowledged the command. The user accepted the terms at 13:42:44 and the session finished at 13:48:20. So do not read Complete as proof that the logs reached Apple; confirm that on the AppleCare case. A token that Apple rejects does show Failed; see Troubleshooting.

Intune does not offer the log bundle for download. The logs go from the Mac straight to Apple, and you review them with AppleCare through the case.

What The User Sees On The Mac

On a Mac nothing is collected until the signed-in user agrees, twice: once to the request and once to Apple’s terms. In my test with test-token-normal, the full run took just under eight minutes from the command arriving to the final screen.

• Notification and System Settings item. The Mac posts a notification and adds an item to System Settings named after the organisation: “Intune-IRL” Requested Logs. The text reads “Your organization is requesting diagnostic logs to help diagnose an issue on this Mac.” The user chooses Continue or Not Now.

• Log Collection. Continue opens the Enhanced Logging app. It explains that Apple needs additional diagnostic logs and that they are sent to Apple once collected. The only button is Continue.

• Terms and Conditions. The user agrees that Apple may collect and keep, for a limited time, identifiers such as the serial number, and that Apple and its partners may use the diagnostic data for troubleshooting. The user chooses Agree or Disagree.

• Collect and Share Diagnostics with Apple. This screen lists what the session collects. With the test token it shows one entry, Test Logs, with the note “No information will be collected from this device.” The user chooses Collect and Share or Review Before Sharing.

• Collection. After Collect and Share, the Mac collects for two minutes with the test token.

• Uploading. The window says the user can close it and keep working. It shows progress (“Compressing files”, 23 KB of 100 KB in my capture) with Stop Uploading and Done.

• Logging Complete. The last screen confirms the session finished. Done closes the app. The item in System Settings disappears on its own once the session is finished.

These timings are for Apple’s test token, which generates a 100 KB mock file. A real AppleCare session collects real diagnostics, so expect different durations.

Logs: What A Healthy Session Looks like

Three processes tell the story on the Mac: mdmclient receives the command, enhancedloggingd runs the session, and ManagedStatusSubscriber reports its status back to Intune.

Run this on the Mac after a session to pull the relevant lines from the last hour:

log show --last 1h --predicate '(subsystem == "com.apple.EnhancedLogging" AND category != "xpc") OR (subsystem == "com.apple.ManagedClient" AND (eventMessage CONTAINS "EnhancedLog" OR eventMessage CONTAINS "Enhanced logging"))'

These are the lines from my test with test-token-normal, in order:

Three things in these logs are worth knowing:

• Intune’s Complete carries the acknowledgement time. The Complete row in Intune is stamped 1:40:37 PM, the second the Mac acknowledged the command and before the user had seen the request.
• The session talks to iCloud. enhancedloggingd saves its events to the CloudKit container com.apple.enhanced-logging-state through gateway.icloud.com.
• The token is written to the log. The test token appears in plain text as sessionTicketID. I have not checked whether a real AppleCare token is logged the same way.

The consent notification itself is posted by enhancedloggingd as a follow-up item named com.apple.enhanced-logging-state.background-consent. Those lines sit under the com.apple.followup subsystem, outside the command above.

ManagedStatusSubscriber publishes the status items enhanced-logging.status, enhanced-logging.applecare-token and enhanced-logging.timestamp under the subsystem com.apple.remotemanagementd. The Mac also loads a fourth item, enhanced-logging.noninteractive-eligibility, which is not in Apple’s public schema.

Where The Collected Logs Go

The logs go from the Mac straight to Apple and are attached to the AppleCare case. Intune never holds a copy, so there is nothing to download in the admin center.

Can you see what was collected?

• The user can review before sending. The Collect and Share Diagnostics screen has a Review Before Sharingbutton. Apple’s guide says the user can review the information before it is uploaded. I did not test this button.
• The admin cannot download the bundle. Microsoft’s documentation says the admin center does not provide a copy. You review the diagnostics with Apple through the AppleCare case.
• The files exist on the Mac during the session, but the log hides where: finished with attachments at <private>.

How the logs are sent

The device log shows the order of the steps:

Alongside this, the Mac reports each stage change to Apple. It saves an EnhancedLoggingEvent record to the CloudKit container com.apple.enhanced-logging-state through gateway.icloud.com, over TLS 1.3. A successful run saved five of these records.

One limit of my test: with a test token, steps 5 and 6 are simulated. The log says Using test tokens as fallback and Starting mock upload. So the test shows the order of the steps, but not which Apple host a real log bundle is sent to.

When It Fails: Two More Scenarios

I ran two more tests to see what a failure looks like in Intune and on the Mac. Together with the successful run, that makes three scenarios:

Scenario 1 is the walkthrough above. The other two follow.

Scenario 2: The Upload Fails

Apple’s test-token-failed runs a normal interactive session and then fails it at the upload stage.

• In Intune, select Remote actions > Trigger enhanced log collection and enter test-token-failed.

• On the Mac, the user gets the same request as in a successful run. The log shows the same sequence: request opened, terms accepted, collection started.
• Collection runs for its full two minutes, then the files are compressed and the upload starts.
• The upload fails. The Mac shows a notification: Upload Failed, “Your log collection session was unable to send logs due to an error. Please contact Apple Support to try again.” The Enhanced Logging app closes a second later.

• In Intune, the device action still shows Complete.

The Mac’s log for this run, trimmed to time, process and message:

11:25:57 mdmclient: Processing server request: TriggerEnhancedLogCollection for:
11:25:57 mdmclient: TriggerEnhancedLogCollection requested with token (length: 17)
11:25:57 mdmclient: Configuring background session with headless policy Require Interactive headless eligible: false
11:25:57 mdmclient: Enhanced logging session configured successfully
11:25:57 mdmclient: >>>>> Sending HTTP request (PUT) [Acknowledged(TriggerEnhancedLogCollection):282555B3-…] >>>>>
11:26:27 enhancedloggingd: acceptTermsAndConditions(sessionID:completionHandler:)
11:26:28 Enhanced Logging: startCollecting(options:) options: 1
11:26:28 enhancedloggingd: Using test tokens as fallback.
11:26:28 enhancedloggingd: Finisher config: <... sessionTicketID: test-token-failed; uploadToken: test-upload-token; ... mockConfiguration: ...>
11:28:28 enhancedloggingd: DE com.apple.TestFileGeneratorDE finished with attachments at 11:28:28 enhancedloggingd: Mock compression starting for session [el-4AE10C-ded:…]
11:28:54 enhancedloggingd: Mock upload starting for session [el-4AE10C-ded:…]
11:29:21 enhancedloggingd: Upload failed: Error Domain=enhancedloggingd.MockFileUploadTaskError Code=1
11:29:21 enhancedloggingd: One or more devices failed to upload
11:29:21 Enhanced Logging: Displaying message for error -5
11:29:22 Enhanced Logging: applicationWillTerminate(_:)

The notification sends the user to Apple Support, not to IT. Since Intune shows Complete, the admin only learns about the failure if the user reports it or someone reads the Mac’s log.

Scenario 3: Apple rejects the token

A token that Apple does not recognise never becomes a session. I used a made-up one, invalid-token-12345.

• In Intune, select Remote actions > Trigger enhanced log collection and enter the token. Intune accepts any text in the field.

• On the Mac, nothing appears: no notification, no item in System Settings, no Enhanced Logging app.
• In Intune, the device action shows Failed. The Details column is empty.

The Mac’s log for this run, trimmed to time, process and message:

12:47:55 mdmclient: Processing server request: TriggerEnhancedLogCollection for:
12:47:55 mdmclient: TriggerEnhancedLogCollection requested with token (length: 19)
12:47:55 enhancedloggingd: No baked payload for ticket 12:47:55 enhancedloggingd: [Canopy] Request FETCH Ticket 12:47:56 enhancedloggingd: Request to failed with status 400: 12:47:56 enhancedloggingd: Failed to fetch payload for : Error Domain=EnhancedLogging.CanopyClientError Code=400
12:47:56 mdmclient: [ERROR] Could not configure enhanced logging session: Error Domain=EnhancedLogging.CanopyClientError Code=400
12:47:56 mdmclient: [ERROR] [ErrorChain.0] (TriggerEnhancedLogCollection) [MDMClientError:70] Could not configure enhanced logging session
12:47:56 mdmclient: >>>>> Sending HTTP request (PUT) [Error(TriggerEnhancedLogCollection):AEE0EA79-…] >>>>>
12:47:57 mdmclient: <<<<< Received HTTP response (200) [Error(TriggerEnhancedLogCollection):AEE0EA79-...] <<<<<

Intune gives no reason for the failure. The 400 is only visible in the Mac’s log. Troubleshooting below explains the key lines of both logs.

Troubleshooting

Intune’s status tells you whether the Mac accepted the token, and nothing about what happened after that. Three tests show the pattern:

Intune Shows Failed

The Mac checks the token with Apple before it sets up a session. My made-up token was rejected in under a second, and the Mac sent Intune an error in place of an acknowledgement. Intune shows the action as Failed with an empty Details column, stamped 12:47:56 PM, the second the Mac sent the error.

What to do: check the token for typing errors or stray spaces, then ask AppleCare for a new one. I tested a made-up token only, so I cannot say how an expired or already used AppleCare token behaves.

Before the lookup, the log also shows No baked payload for ticket. With a test token it shows Using test tokens as fallback. My reading is that the test tokens are built into macOS, which would explain why they work without an AppleCare agreement.

Intune shows Complete, but AppleCare has no logs

Complete is stamped when the Mac acknowledges the command. After that the user still has to open the request, agree to the terms and let the upload finish.

1. Ask the user whether “<Organisation>” Requested Logs is in System Settings. If it is, the session has not been started.
2. Ask whether they saw an Upload Failed notification. It tells them to contact Apple Support, so they may not think to tell IT.
3. Run the command from the Logs section and search for these lines:

With test-token-failed the error is enhancedloggingd.MockFileUploadTaskError Code=1. That is a simulated error, so a real failure will name a different one. In my test collection ran its full two minutes and the failure came 53 seconds later, at the upload stage.

Nothing happens on the Mac

The command waits for the Mac’s next check-in. In three tests that took 3 minutes 38 seconds, 5 minutes 15 seconds and 6 minutes 9 seconds after the request in Intune. The command also uses the user channel, so per Apple’s schema a user has to be signed in. I did not test a Mac at the login window.

Log lines you can ignore

• Failed to parse receipt at /System/Library/CoreServices/Enhanced Logging.app/Contents/_MASReceipt/receipt from mdmclient. It appeared 12 times in a broad log search, including before I sent any command.
• Session is inactive status, attempting to flush. A new trigger clears the previous, finished session before it sets up the next one.

Wrap-up

Remote log collection works on macOS 27 from Intune today, and you can rehearse the whole flow with Apple’s test tokens before you need it for a real case.

What to take away:

• The trigger is one remote action and one token. The token comes from AppleCare through a support case.
• The user decides. On a Mac the session is always interactive, so nothing is collected until the signed-in user agrees.
• Read Intune’s status carefully. Complete means the Mac accepted the token. Failed means Apple rejected it. Neither tells you how the session ended.
• Confirm the result elsewhere. Check the AppleCare case for the logs, or the Mac’s log for Upload failed.
• Expect a delay. The command waited 3.5 to 6 minutes for the Mac’s next check-in in my tests.

More parts of this WWDC26 series will follow.