Change in Audit Records for Teams Meeting Recordings Since 2021

Three years ago, I wrote about how to use audit records to track the creation of Teams meeting recordings. The idea was to find the audit records created when a Teams meeting recording was uploaded to OneDrive for Business or SharePoint Online.

Time marches on and old blogs rot, as do old PowerShell scripts. Three years ago, Microsoft hadn’t completed the transition from Stream classic to Stream on SharePoint. The migration finished recently and Microsoft has moved to standardize how Teams meeting recordings and transcripts are stored in OneDrive for Business. Of course, OneDrive only holds recordings for personal meetings. Recordings for channel meetings, including Meet Now in the channel, end up in the SharePoint Online site belonging to the host team.

Closing a Compliance Gap

While some might think that I spend endless hours examining audit records, this is a fallacy. I check on an as required basis, which means that I didn’t notice that my script wasn’t working quite so well because the format of the audit records changed. One important change is that the user noted in all the audit records is app@sharepoint, the ubiquitous SharePoint utility account. No trace exists in the audit records about the user who recorded the meeting, as had happened before.

From a compliance perspective, this is a big deal. Audit records exist to track the actions taken by individuals and system processes, and in this case, it seems important to know who initiated a recording.

Unfortunately, there’s nothing in the audit record to indicate who initiated the recording of a channel message, so we’re left with the SharePoint app. Recordings for personal meetings used to end up in the OneDrive account of the user who started the recording (the organizer or a presenter). Some time ago, Microsoft changed this to a more logical arrangement where recordings always go into the meeting organizer’s OneDrive account. The URL of a OneDrive account contains the site URL, like:

https://office365itpros-my.sharepoint.com/personal/jane_ryan_office365itpros_com

Figuring Out the OneDrive Site Owner

It’s easy for a human to read the URL and know that the OneDrive account belongs to Jane.Ryan@office365itpros.com. With time, I could parse the URL to extract the email address, but I went for a simpler (faster) approach. I used the Get-SPOSite cmdlet from the SharePoint Online PowerShell module to fetch the set of OneDrive accounts in the tenant and created a hash table from the site URL and site owner. It’s fast to check the hash table with the site URL taken from an audit record to return the user principal name of the site owner:

$User = $OneDriveHashTable[$AuditData.SiteURL]
If ($null -eq $User) {
   $User = "SharePoint app"
}

Changes in Search-UnifiedAuditLog Too!

Another influence on the output was the change made by Microsoft in summer 2023 to how the Search-UnifiedAuditLog cmdlet works. Microsoft have denied to me that they did anything, but the evidence shows that:

• The SessionCommand parameter must now be set to ReturnLargeSet to force the cmdlet to return more than 120 records.
• Many more duplicate records are returned than before. This necessitates sorting by the unique audit event identifier to remove the duplicates.
• Search-UnifiedAuditLog returns unsorted data. If a sorted set is important to you, make sure that you sort the audit records by creation date.

$Records = $Records | Sort-Object Identity -Unique | Sort-Object {$_.CreationDate -as [datetime]} -Descending

Of course, you can try to run high completeness searches with Search-UnifiedAuditLog, but I have not had good luck with this preview feature.

Figure 1 shows the output from the updated script, which is available from GitHub. Normal service is resumed.

A Reminder to Check Audit Log Analysis Scripts

It would be nice if a script lasted a little longer, but the ongoing change within Microsoft 365 means that PowerShell developers need to keep a wary eye on updates that might affect production scripts. In this instance, the confluence of the Stream migration and the change to the Search-UnifiedAuditLog cmdlet made a mess of a perfectly good script. I guess life is like that sometimes. Maybe now is a good time to check your scripts that use the Search-UnifiedAuditLog cmdlet.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

Cloud App Security Alerts Join the Office 365 Audit Data

Office 365 keeps on changing. The recent announcement that Microsoft is surfacing Office 365 Cloud App Security alerts through extra interfaces is an example of a change that might be considered small, unless you work in the area of security and compliance.

One thing that attracted my attention is the fact that Office 365 Cloud App Security (bundled with E5 licenses) now sends its alerts to the Office 365 audit log. This makes sense because Office 365 alerts and alert policies are powered by the events captured in the audit log.

Analyzing Cloud App Security Audit Records

In any case, events in the audit log show up with RecordType SecurityComplianceAlerts. Like all events in the audit log, some work is needed to unpack and interpret the information stored in the AuditData property. I used some code from Chapter 21 of the Office 365 for IT Pros eBook to examine what useful material is included by running the Search-UnifiedAuditLog cmdlet to retrieve the records.

Office 365 audit log records are normalized, but only to a point. Normalization means that a set of the same basic fields are included in all records, no matter what workload generates a record. The devil in the detail is that the contents of the AuditData property is open to interpretation and each workload can do its own thing in terms of what is output. And in the case of Cloud App Security, the contents of AuditData vary depending on an alert.

The upshot is that more work than should be necessary is needed to parse the data to make it useful for reporting and analysis. I only found two types of alerts generated by Cloud App Security, so that’s what the code below deals with. You might find others and need to update the code to handle whatever Microsoft decided to stuff into AuditData for the alert.

$Records = (Search-UnifiedAuditLog -RecordType
SecurityComplianceAlerts -StartDate 1-Jan-2019 -EndDate 30-Jan-2019 -Formatted
-ResultSize 3000)
If ($Records.Count -eq 0) {
   Write-Host "No alert audit records found." }
Else {
   Write-Host "Processing" $Records.Count "audit records..."
$Report = @()
ForEach ($Rec in $Records) {
   $AuditData = ConvertFrom-Json $Rec.Auditdata
   $Data = ConvertFrom-Json $Auditdata.data
   If ($Rec.Operations -eq "AlertTriggered") {
      $ReportLine = [PSCustomObject]@{
           TimeStamp; = $Rec.CreationDate
           User        = $Data.f3u
           Action      = $Data.an
           Status      = $AuditData.ResultStatus
           Severity    = $AuditData.Severity
           Workload    = $AuditData.Source
           Operation   = $Rec.Operations
           Category    = $AuditData.Category }
      $Report += $ReportLine}
    Else {
      $ReportLine = [PSCustomObject]@{
           TimeStamp   = $Rec.CreationDate
           User        = $Data.eid
           Action      = $Data.lon
           Status      = $AuditData.ResultStatus
           Severity    = $AuditData.Severity
           Workload    = $AuditData.Source
           Operation   = $Rec.Operations
           Category    = $AuditData.Category }
        $Report += $ReportLine}
  }} 

$Report | Select Timestamp, Operation, User, Action
Processing 42 audit records...

TimeStamp            Operation            User          Action
---------            ---------            ----          ------
21 Jan 2019 16:58:00 AlertEntityGenerated Tony.Redmond@ eDiscoverySearchStartedOrExported
21 Jan 2019 16:58:00 AlertTriggered       Tony.Redmond@ eDiscovery search started or exported
2 Jan 2019 19:54:00  AlertTriggered       Tony.Redmond@ eDiscovery search started or exported
…

It’s worth pointing out that some of the alerts that flow into the audit log duplicate events already logged by a workload, which is certainly the case for the eDiscovery searches featured above.

Always Tracking New Developments

We’ll continue to track what happens as Microsoft releases the other updates mentioned in their post and update whatever we need to in the Office 365 for IT Pros eBook. Keeping up-to-date with developments inside Office 365 is what we do!