Find and Analyze How People Use Emojis as Teams Reactions

An interesting LinkedIn post expressed the opinion that it’s easier to learn some new technology by doing something fun with it. In this case, the author shows how to use KQL to interrogate Microsoft 365 audit data stored in Microsoft Sentinel to analyze the use of Teams emoji reactions for messages. Essentially, the idea is that if you can master KQL to query Sentinel data for emoji usage, you can do the same for more serious activities.

I decided that it would be a good idea to show how to do the same with PowerShell based on audit records from the unified audit log. The same data drives both repositories, so the same results should be achievable. I’ve added a little bit of extra value by showing how to display the emojis instead of just the emoji names, and I also report user display names instead of user principal names.

Teams Emojis

Teams offers a wide range of “fluent” emojis that people can use to react to chat and channel messages. Tenants can add their own custom emojis to the set provided by Microsoft. Up to twenty emojis can be used to react to a message. Basically, you can go wild with emojis should you like to react to messages in a blizzard of colorful emotions.

Audit events are captured when people use emojis to react to Teams chat and channel messages. Each emoji counts as a separate reaction, and each reaction is logged as a ReactedToMessage audit event.

Scripting the Emoji Analysis

The code in the script to analyze the use of emojis in Teams reactions is not very complex. Here’s what I did:

• Run Connect-MgGraph to connect to the Microsoft Graph PowerShell SDK to fetch details of user accounts (display names and user principal names). Because these are base properties, only the User.ReadBasic.All permission is needed. If you don’t want to see display names in the report, you don’t need this code.
• Run Connect-ExchangeOnline to connect to the Exchange Online management endpoint.
• Create a hash table and populate it with user principal names (keys) and display names (values). This data is used to translate the user principal names found in audit events into display names for the report.
• Create a hash table of emoji keyed on the emoji name and with the emoji graphics as the values. Microsoft doesn’t document the full set of Teams emojis, but I found this page useful. The hash table contains about 80 emojis from the full set. These are the emojis used in my tenant. Your tenant might differ, in which case you’ll need to add more key-value pairs to the hash table.
• Run the Search-UnifiedAuditLog cmdlet to find events with the ReactToMessage operation. If events are found, the script removes duplications (which can happen in audit results).
• Loop through the audit records and create a report of what’s found. The report includes instances where reactions are added or removed to chats or channel messages.
• Generate an Excel worksheet containing the data (if the ImportExcel module is not installed), the script creates a CSV file instead. Figure 1 shows some data extracted from my tenant.

The data can also be used for basis analysis. For instance, here’s how to find the count of the ten most used emojis, including the emoji fetched from the hash table:

Write-Output "Top Ten Emoji reactions used in Teams"    
$Report | Group-Object Reaction -NoElement | Sort-Object Count -Descending | Select-Object -First 10 | Format-Table Name,  @{name="Emoji"; Expression = { $Emojis[$_.Name] }}, Count -AutoSize

Top Ten Emoji reactions used in Teams

Name                      Emoji Count
----                      ----- -----
like                            334
heart                           109
laugh                            31
surprised                        26
yes-tone1                        18
1f4af_hundredpointssymbol         8
like (Removed)                      8
follow                            7
handsinair                        7
fire                              7

And here’s how to find the top 10 emoji users:

$Report | Group-Object User -NoElement | Sort-Object Count -Descending | Select-Object -First 10 | Format-Table Name, Count

Name                                    Count
----                                    -----
Paul Robichaux | Keepit                   122
Christina Wheeler                         112
Tony Redmond                               96
Tony Sterling (Teams)                      67
Leah Theil | Keepit                        61
Juan Carlos González Martín                44
Michel de Rooij (MVP)                      41
Leah Theil                                 31
Ben Lee                                    18
Sean Landy (Office 365 for IT Pros)        11

A Learning Exercise

I doubt if the script (which you can download from the Office 365 for IT Pros repository) has any great business value. But learning how to access data in the unified audit log is a core skill for a Microsoft 365 tenant administrator. Being able to manipulate the audit data with PowerShell makes the data more powerful, and that’s why we learn how to do these things.

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. Only humans contribute to our work!

Microsoft Adds Last Used Property for Authentication Methods

The Microsoft 365 User Password and Authentication report is one of the scripts that I pay attention to and attempt to keep up to date as new developments emerge. The last version (V1.4) dealt with a change in how the default MFA method is reported; the version before added details of the authentication methods configured for user accounts.

Now it’s time to go back to refresh the script again because Microsoft has refreshed the beta version of the list authentication methods API to add a last used date time property. Entra ID updates the property when the authentication method (SMS code, passkey, Microsoft authenticator app, and so on) is used to authenticate an account. Looking at the dates in my tenant, I see last used dates going back to January 2023. There might be earlier dates than this noted for some authentication methods, but the point is that this information is now available.

The Value of the Last Used Property

The value of the last used property is that if you know what authentication methods are in active use, you might be able to remove unused authentication methods from user accounts to reduce the available attack surface for those accounts.

In any case, knowing when authentication methods are in active use for accounts is good information to have, especially if you want to encourage (“nag”) people to move away from weak secondary authentication methods like SMS and use something stronger, like the authenticator app or passkeys.

Updating the Script to V1.5

In any case, it was time to break out Visual Studio Code to update the Microsoft 365 User Password and Authentication script. The code uses the Get-MgUserAuthenticationMethod cmdlet to fetch authentication methods for an account. Each method has an identifier, and the more interesting information is found in the additionalProperties property (array). You’ll need at least the UserAuthMethod-MicrosoftAuthApp.Read.All Graph permission to access this information:

[array]$AuthMethods = Get-MgUserAuthenticationMethod -UserId $User.Id -ErrorAction Stop
$AuthMethods

Id
--
28c10230-6103-485e-b985-444c60001490
3ddfcfc8-9383-446f-83cc-3ab9be4be18f
338e704e-bb5c-4b0d-9c2e-458e630e4017

Microsoft updated the Microsoft Graph PowerShell SDK to V2.32 earlier this month. So far, the release has proven stable, and I haven’t run into new problems. It includes the Get-MgBetaUserAuthenticationMethod cmdlet, which returns the last used property:

[array]$AuthMethods = Get-MgBetaUserAuthenticationMethod -UserId $User.Id -ErrorAction Stop
$AuthMethods

Id                                   CreatedDateTime     LastUsedDateTime
--                                   ---------------     ----------------
28c10230-6103-485e-b985-444c60001490 30/05/2020 07:48:05
3ddfcfc8-9383-446f-83cc-3ab9be4be18f
338e704e-bb5c-4b0d-9c2e-458e630e4017                     04/08/2025 06:27:29

Not all authentication methods update the created date and last used date properties, but enough do to make the properties worthwhile.

The interesting thing here is that the cmdlet now surfaces the created date time as a property instead of an item in the additionalProperties array. This change is likely due to an update to the underlying Graph API metadata, and it could result in some scripts breaking if, as expected, the change makes it through to production. I certainly had to make some code changes to accommodate the change in how the created date is exposed. Figure 1 shows some example output where the last used date is reported for two authentication methods.

It would be nice if the data provided for every authentication method was consistent, but it’s not. It’s just another challenge to solve when working with Graph data.

New Version Available from GitHub

The updated (V1.5) version of the script can be downloaded from the Office 365 for IT Pros GitHub repository. I make no claim of greatness for the code. It’s there for people to learn about how to access and use the Graph to interact with authentication methods. No doubt this will interest some and not others. Feel free to upgrade and enhance the code to meet your requirements.

Learn about managing Entra ID and the rest of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.

New Management Wants to Reimagine Outlook but That Doesn’t Mean That the New Outlook Client is Dead

A Tom Warren report in TheVerge.com that Outlook is getting an AI overhaul under new leadership (reported here in an accessible form) certainly caused the imagination of some commentators to go into overdrive. Unfortunately, the conclusions reached are impractical and unlikely. Let me explain why.

The article reported that Gaurav Sareen, corporate VP of global experiences and platform at Microsoft wants the Outlook developers to reimagine how Outlook can serve users by using AI to process email in a much more proactive manner than happens today.

Essentially, Outlook should be like a hyper-efficient assistant that processes email to relieve mailbox owners of the need to review and decide how to handle messages. According to the internal memo seen by Warren, Sareen wants developers to take a new approach: “Instead of bolting AI onto legacy experiences, we have the chance to reimagine Outlook from the ground up.” More importantly, Sareen wants work to happen faster with teams “prototyping and testing in days, not months.”

Senior managers have a habit of laying out grand plans when they take over new responsibilities. That’s OK, because it’s important to have a vision for where a product or technology is heading, so no one can criticize Microsoft executives for setting out how they think development teams should react to the current state of the market and customer demand.

However, Outlook is in the middle of a transition to fulfil the “One Outlook” vision of clients that deliver the same functionality on Windows, Mac, browsers, and mobile clients. The transition from Outlook classic is ongoing, and while I have been critical of the rate of progress and the implementation of some features (like the very slow export to PST), there’s no doubt that Microsoft is making progress. The eventual goal is to be able to transition away from Outlook classic by the time support for the classic client finishes in 2029.

The need to deliver certainty to corporate customers means that it makes zero sense for commentators to conclude that Microsoft will now dump the new Outlook in favor of some AI-infused client that must be designed from the ground up to replace Outlook classic, OWA, Outlook mobile, and the new Outlook.

Microsoft’s Outlook Commitment to Microsoft 365 Customers

Microsoft has a commitment to Microsoft 365 customers to deliver a solid version of Outlook as part of the Microsoft 365 enterprise apps suite. Changing course now to incorporate new AI-powered functionality might sound exciting, but it ignores the simple fact that Microsoft 365 Copilot licenses are not possessed by many tenants, and without Copilot and access to AI-powered features, the vision outlined by Sareen cannot be achieved.

I don’t think Microsoft is willing to give away Copilot licenses just to enable AI features in Outlook. That move wouldn’t go down well with shareholders who look at the massive investments made to build out datacenter capabilities for AI without a clear line of sight about how these investments will deliver revenues.

Microsoft is coy about many Microsoft 365 Copilot licenses they’ve sold. No one knows how many Microsoft 365 Copilot licenses are in active use, but I’m willing to bet that the number of Copilot licensees is hundreds of millions removed from the number of Outlook users. The latest data from the Microsoft FY26 Q1 results indicate that Microsoft 365 has around 446 million paid seats. Let’s say that 400 million of these people use Outlook. That’s a lot of additional AI processing that might be required to deliver a new AI-infused Outlook client, which is why I think that any strategy based on dramatically increasing the amount of AI processing in Outlook will run into the cold brick wall of financial reality.

There’s also the need for Microsoft to deliver a client Exchange Server after Outlook classic retires. This client is unlikely to have as many AI-powered features because it’s much harder to deliver those features in on-premises environments than it is in the cloud.

Evolutionary AI Additions to Outlook

What I think will happen is that Microsoft will continue to press ahead with its One Outlook strategy to equip the new Outlook with equivalent functionality (and more) than is currently available in Outlook classic. It just makes sense for Microsoft to get Outlook to a common code base for multiple platforms.

At the same time, during the period up to 2029 when Microsoft’s committed support for Outlook classic ceases, Microsoft will implement important AI-powered features in Outlook classic to keep corporate customers happy.

At the same time, I believe that Sureen’s memo will force the Outlook development teams to respond with proposals to become more aggressive about bringing AI-powered features into Outlook based on the new Outlook framework. I don’t see any appetite for a third Outlook flavor over the next few years (Outlook classic, new Outlook, and Outlook AI++). That’s not how Microsoft works, especially in a space where they need to keep large corporate customers happy and don’t want to see support costs escalate due to client profusion.

Customer Support and Expectations Moderate Grand Plans

As noted above, new leaders invariably have new ideas about how to move products forward. Just because some of those ideas leak outside is no reason to conclude that Microsoft will suddenly switch course for a product used by hundreds of millions of people. The practical issues of customer expectations and long-term support are enough to moderate even the most radical of new leader ideas. I suspect that the same will happen here. Stay calm and take some happy pills.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.