Table of Contents
Clamping Down on Access to Non-IPM Folders Stops App from Fetching Copilot Interactions
In November 2024, I published an article explaining how to use the Microsoft Graph PowerShell SDK to analyze the compliance records for Microsoft 365 Copilot prompts and responses. The compliance records are stored in a non-IPM folder called TeamsMessagesData, along with the compliance records for Teams chats. A non-IPM folder is one of the hidden folders that exists in user mailboxes which isn’t accessible through “regular” clients like Outlook. Specialized utilities like MFCMAPI can access non-IPM folders.
Last month, I tried to run the code for the first time in a couple of months only to find that the Get-MgUserMailFolderMessage cmdlet returns an error. Here’s some same code to illustrate the issue. TeamsMessagesData is a well-known folder like the Inbox or Deleted Items folders, so you can pass the name rather than a folder identifier:
$UserId = (Get-MgContext).User
[array]$Items = Get-MgUserMailFolderMessage -UserId $User.Id -MailFolderId 'TeamsMessagesData' -All -PageSize 500
Get-MgUserMailFolderMessage_List:
Line |
2 | [array]$Items = Get-MgUserMailFolderMessage -UserId $User.Id -MailFol …
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Not allowed to access Non IPM folder.
Status: 403 (Forbidden)
ErrorCode: ErrorAccessDenied
I knew that Microsoft had restricted the ability to use Exchange Web Services to access the TeamsMessagesData folder (a decision that delighted many backup vendors who used EWS to copy Teams compliance records) but hadn’t seen anything similar relating to the Graph APIs.
Not Much Can be Done
There’s no way around the block. The Graph intercepts every attempt to retrieve items from the TeamsMessagesData folder and responds with the 403 error. Microsoft uses different APIs to access the folder when the Microsoft 365 substrate creates compliance records and Purview solutions like eDiscovery and Communication compliance read the compliance records.
I can’t think of any damage that could be done by reading details of Copilot compliance records to discover what the records contain, but obviously someone in Microsoft decided to stop Graph-based applications from being able to read items in non-IPM folders.
I guess I shouldn’t have been surprised. Ever since the Midnight Blizzard attack in 2024 exposes flaws in Microsoft 365 infrastructure and protocols, Microsoft has been steadily finding and closing off holes and potential weaknesses, no matter how small. Another example relating to mail items is the change to limit app access to sensitive message properties, which is due to kick in at the end of 2026.
The aiInteractionHistory Alternative
Instead of reading compliance records, we can use the Graph aiInteractionHistory API. The API works, and the only problem is to figure out what the interaction records contain. It’s the same kind of game that we play when interpretingthe audit data payload for Purview audit records.
I updated the script for the last article to use the production version of the current aiInteractionHistory API. The script can be downloaded from the Office 365 for IT Pros GitHub repository. It fetches the Copilot interactions for the last month for a user and reports the number for each app and does some elementary calculations:
Copilot interactions for Tony Redmond between 04-May-2026 and 04-Jun-2026 Name Count ---- ----- Microsoft 365 Chat 544 Tony Redmond 346 Copilot in Word 128 Copilot in SharePoint 18 Microsoft Copilot 16 Copilot in OfficeCopilotSearchAnswer 14 Copilot in Teams 4 Outlook 1 128 of the 1071 interactions are automatic (11.95%) 346 of the interactions are user prompts (32.31%)
One thing that I noticed is that the body of AI responses is often a value like <attachment id=”f0150a5983e94abcb9b079ffc322697b”></attachment> (Figure 1). The body is a pointer to an internal file containing the formatted body of the AI response.
When you dig into the data, the identifier in the body is a pointer to a value held in the Attachments property of the interaction record. This is where we find the real text of Copilot’s response in a kind of Markdown format with some HTML thrown into the mix. To extract clean text from the response, we need to do something like this (where $Record holds a Copilot interaction returned by the aiInteractionHistory API):
Add-Type -AssemblyName System.Web $OriginalText = $record.attachments[0].content | ConvertFrom-json $CleanText = [System.Web.HttpUtility]::HtmlDecode($OriginalText.body.text)
There’s a bunch of other conditions to deal with for interactions capturing the automatic summaries for Word documents and other automatic responses. I’ve dealt with the conditions I came across in the script code but cannot pretend that other conditions might arise that code changes are needed to handle. For now, the code works and generates what I need (Figure 2):
No Way Round So We Miss Some Data
The aiInteractionHistory API gives access to Copilot interaction data and is a good replacement for Graph access to compliance records, providing you do the work to extract all the information from the records returned by the API and you’re only interested in tracking interactions for people with Microsoft 365 Copilot licenses. The compliance records captured for users also include Microsoft Copilot interactions (the free version). Not being able to report those interactions is a reduction in functionality.
Fortunately, eDiscovery searches for Copilot content finds both Microsoft 365 Copilot and Microsoft Copilot interactions. In addition, investigators want to see exactly how Copilot responded to a user prompt can view transcripts of Copilot interactions that include all the prompts and responses.
So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive insights updated monthly into what happens within Microsoft 365, why it happens, and what new features and capabilities mean for your tenant.