No Room for Microsoft Search in Bing in a World Increasingly Dominated by Copilot

In a change that might be linked to the ever-increasing influence of Copilot across Microsoft 365, Microsoft announced (MC961557, 19 December 2024) their intention to remove Microsoft Search in Bing on March 31, 2025. Microsoft says that the decision is the result of their work to “streamline search experiences and focus on enhancing core productivity tools.” A more truthful assessment might advance the case that Microsoft 365 Copilot (BizChat) is now the preferred way for customers to integrate work and web search results, even if that means that a free facility is being replaced by one costing $360/user annually.

Microsoft introduced Microsoft Search by Bing in May 2019. The idea is simple: connect the search indexes generated by Microsoft Search from Exchange, SharePoint, OneDrive, and Teams content and make the data available through searches run from bing.com. Figure 1 shows the “work” results generated by searching bing.com for “Search in Bing.” Depending on what Bing finds, other results might be available under messages (Teams and Outlook), sites, and people.

The integration works well for people whose preferred search engine is bing.com. Once you sign into your tenant account, Bing automatically looks for matches in work sources. The problem is that bing.com is not heavily used, with industry assessments putting its use at around 10% of the desktop search engine market.

Microsoft 365 Copilot Uses Bing

Removing Microsoft Search in Bing doesn’t mean the disappearance of Bing-based searches from Microsoft 365. BizChat and Microsoft Copilot both use Bing to search web sources. Bing is not my favorite search engine and some of the web-based results I see in Copilot leave me wondering where they came from. However, it cannot be denied that Copilot does a much better job of stitching work and web results together to answer user questions.

Tags Being Retired Too

Microsoft Search in Bing lasted nearly five years. The tags feature, introduced in December 2023 to allow users to categorize content “in a way that makes sense to you,” is getting an accelerated retirement and will disappear from the Microsoft 365 app starting on January 6, 2025, and will be completely gone by January 10 (MC961601). The speed of withdrawal indicates that not many people use tags. This isn’t at all surprising given the very low level of utility delivered by the feature.

You can define and apply tags to files through the Microsoft 365 app (Figure 2) but then what? There’s nothing else you can do except apply a tag to add a small splash of color to the details shown for files. It seems like this was a feature introduced without much thought and no follow-up.

The Microsoft 365 app is due to be overhauled in mid-January 2025 (MC958905, 16 December 2024) and the demise of tags is probably an outcome of the review to decide what to keep and what to drop from the app.

Don’t Worry About Retirements

There’s been a spate of retirements within Microsoft 365 recently. Office Delve retired earlier this month and Microsoft announced that Viva Goals will retire in December 2025. Tenant administrators can be forgiven for thinking that the functionality offered by Microsoft 365 is a tad unstable.

The fact is that change happens all the time in the cloud. Office 365 and Microsoft 365 have seen retirements in the past. No product has a guaranteed right to succeed. Some will launch and discover soon afterward that the expected market is just not there. Others will have a burst of initial success and decline thereafter. If a Microsoft 365 product isn’t successful, it won’t last long. Another recent factor seems to be that the availability of engineering resources has tightened because more people are working on Copilot-related features. The pressure is on to reduce effort on non-core or underused features, which is what might have eventually killed Microsoft Search in Bing.

Kaizala, StaffHub, Cortana Scheduler are three examples of products that appeared and disappeared without trace. Viva Topics was retired earlier this year, and Sway is on life support. Yammer was the great hope of 2014 that had to reinvent itself as Viva Connections to stay relevant after Teams came along and became the focus of chat-based collaboration within the suite.

On that thought, this blog will take a short break until the New Year. Over that period, the Office 365 for IT Pros eBook team will still be busy preparing the January 2025 update, including figuring out how to cover the change discussed here. I hope that you all get some well-deserved rest over the holidays and come back refreshed for new (or renewed) challenges in the big, bad world of Microsoft 365 in 2025.

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 monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Copilot Inference and Evaluation Policy Blocks Copilot in Teams from Interpreting Participant Emotions During Meetings

One of the interesting things about using Microsoft 365 Copilot in Teams meetings (or rather Copilot in Teams, for it’s only one of the many Copilots licensed by Microsoft 365 Copilot) is that it attempts to evaluate user sentiment based on their contributions to meetings. Copilot does this by analyzing the words spoken by participants to “infer emotions, make evaluations, discuss personal traits, and use context to deduce answers.”

Evaluating how happy someone is during a meeting sounds a bit too much like big brother oversight to many, especially in countries where personal privacy is more highly prized than in others. In your organization is in this situation, tenant administrators can restrict “Copilot’s ability to make inferences or evaluations about people or groups when prompted to do so by users” by updating the Copilot inference and evaluation policy.

A Simple Graph Query

Microsoft explains how to update the policy in message center notification MC916990 (last updated 16 December 2024, Microsoft 365 roadmap item 411568). Deployment to tenants with Microsoft 365 Copilot licenses is now complete.

MC916990 describes how to use the Graph Explorer to update the policy. Much as I like the Graph Explorer, the description given isn’t very clear and lacks some essential detail, like how to format the JSON input payload (Figure 1) and the required permission.

The Copilot Admin Limited Mode Resource Type

Here’s some of that detail together with instructions about how to do the job with the Microsoft Graph PowerShell SDK. The first thing to know is that the Copilot inference and evaluation policy is represented in the Graph by the copilotAdminLimitedMode resource type. This is important to know, because we can then reference the documentation to discover that the CopilotSettings-LimitedMode.ReadWrite permission is needed to update the policy. This is a delegated permission, so it works in the context of the signed-in user, and only accounts with the Global administrator or Global reader roles can update policy settings.

The documentation for the Get and Update operations doesn’t include any Microsoft Graph PowerShell SDK cmdlets to get and update the policy, but we can use the HTTP URI to interact with the policy through the Invoke-MgGraphRequest cmdlet.

To begin, let’s sign into a Microsoft Graph PowerShell SDK interactive session and request the necessary permission.

Connect-MgGraph -Scopes CopilotSettings-LimitedMode.ReadWrite

If CopilotSettings-LimitedMode.ReadWrite is not in the static list of permissions held by the service principal for the Microsoft Graph Command Line Tools app, you’ll be prompted to grant consent (Figure 2):

Next, let’s fetch the current policy values by running Invoke-MgGraphRequest with a Get request to the URI for the policy. The values shown below are the defaults:

$Uri = "https://graph.microsoft.com/beta/copilot/admin/settings/limitedMode"
$Data = Invoke-MgGraphRequest -Uri $Uri -Method GET

$Data

Name                           Value
----                           -----
isEnabledForGroup              False
groupId
@odata.context                 https://graph.microsoft.com/beta/$metadata#copilot/admin/settings/limitedMode/$entity

To update the policy and block Copilot evaluating sentiment for some users, you must create a group and populate its membership with the user accounts to block. Then find the object identifier for the group and copy it for reuse (Figure 3).

You can then use the group identifier to update the group settings. This code creates a hash table to hold the two settings to update. The first setting contains the group identifier (stored in a PowerShell variable). The second sets the value for the isEnabledForGroup setting to true for the members of the group. The effect is to instruct Teams to use limited mode for the members of the group when they are meeting participants. When the hash table is ready, run Invoke-MgGraphRequest again to patch the policy with the settings in the hash table.

$GroupId = 'f805d711-c4f4-4663-9993-b08b4be52cb5'
$Parameters = @{}
$Parameters.Add("groupId",$GroupId)
$Parameters.Add("isEnabledForGroup",$true)

Invoke-MgGraphRequest -Uri $Uri -Method Patch -Body ($Parameters | ConvertTo-Json)

The policy update can take up to a day before it is effective. When it is, Copilot will decline to answer questions about someone’s performance, emotions, or personal traits. Figure 4 shows two examples. The first is the same example as used in Microsoft’s announcement: ask if someone is happy based on their contributions to a meeting. The second asks who made the most positive contribution to the conversion.

In contrast, Figure 5 shows how Copilot responds to the same question asked by another meeting participant who isn’t restricted by policy.

Stop Big Brother Oversight

I’m not sure that many people ask questions about the feelings or emotions of other meeting participants. It seems like a kind of weird thing to do, and I can appreciate that some would find the prospect of AI measuring their emotions to be on the wrong side of big brother observation. With that thought in mind, this is a good update that organizations with Copilot should consider implementing.

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.

Poorly Thought-Out Decision will Reduce the Effectiveness and Usefulness of the Search-UnifiedAuditLog Cmdlet

On December 12, Microsoft published message center notification MC955752 to inform tenant administrators of a fundamental and problematic change in the way the Search-UnifiedAuditLog cmdlet behaves. In a nutshell, Microsoft proposes to make high completeness searches the only type of supported audit log search. That would be fine if these searches worked and were capable of finishing in a reasonable time. The problem is that high completeness searches are unreliable and take too long to complete.

Microsoft says that high completeness searches focus on retrieving a complete set of audit results in response to administrator queries. By contrast, they characterize the current behavior of the Search-UnifiedAuditLog cmdlet as speedy but can return “a subset of results.” My experience is that the current default tends to return too many results, which is why you should always sort the output set to exclude duplicates.

Microsoft then goes on to say that, out of the goodness of their hearts, they’re changing the way the Search-UnifiedAuditLog cmdlet works so that it will always run high completeness searches starting in late January 2025. To be fair, Microsoft notes that “search queries may take longer to finish.” I guess that they cannot get away from the fact that high completeness searches take between ten and twenty times longer to complete than the current searches.

A Complete Mess

I dislike the proposed change because I believe that making all audit log searches “highly complete” will affect scripts running in production today in ways that Microsoft has not anticipated.

As far as I can tell, the developers think about audit log searches as simple activities to recover audit log data. Those working with tenants use audit log searches for many other purposes, from forensic investigations following potential attacks to extracting audit results on an ongoing basis for ingestion into an external SIEM. Some ISVs use the cmdlet to extract audit information for their customers to use as the basis for some reporting.

Another example is where Microsoft engineering uses the Search-UnifiedAuditLog cmdlet to find evidence of the Exchange Web Services App Impersonation RBAC role in use. The script provided by Exchange engineering quickly becomes unusable when every iteration to find audit records takes ten minutes to complete.

Many scripts call the Search-UnifiedAuditLog cmdlet to find evidence of specific user activity. The searches might return just one or two records, enough to prove that someone is active, or they might deliver a more comprehensive assessment of the actions taken by a user account during a day. Waiting for ten minutes for a high completeness search to complete makes it impracticable for these scripts to use Search-UnifiedAuditLog (or the Graph API).

The Unreliability of High Completeness Searches

An even bigger problem is the unreliability of high completeness searches. I pointed this problem out when Microsoft released the feature in preview in April 2024. Things don’t seem to have improved much since. As an example, I ran the script to find SharePoint file operations to identify the last accessed time for documents, which is information that the Graph API for SharePoint cannot return. The search u looks for specific operations over a set period and is typical of the normal usage in Microsoft 365 tenants:

Write-Host ("Searching for SharePoint file operations in the {0} site between {1} and {2}" -f $TargetSite, $StartDate, $EndDate)
[array]$Records = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -RecordType "SharePointFileOperation" -ResultSize 5000 -SessionCommand ReturnLargeSet -Formatted -ObjectIds $TargetSearchSite
If (!($Records)) {
    Write-Host "No audit records found"
    Break
}
# Remove any duplicates
$Records = $Records | Sort-Object Identity -Unique | Sort-Object {$_.CreationDate -as [DateTime]} 
Write-Host ("{0} SharePoint Online file operations audit records found" -f $Records.Count)

Running against the site I use to store the source documents for articles, a normal search retrieved 3,879 records in 31.02 seconds. This time included the sort to remove duplicates. Running the same search with the high completeness flag set resulted in a series of failures. For example:

Measure-Command {[array]$Records = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -RecordType "SharePointFileOperation" -ResultSize 5000 -SessionCommand ReturnLargeSet -Formatted -ObjectIds $TargetSearchSite -HighCompleteness}

WARNING: Failed to process request via HighCompleteness flag, returning HttpRequestException. Exception: InternalServerError , Reason: Internal Server Error.

Days              : 0
Hours             : 0
Minutes           : 8
Seconds           : 11
Milliseconds      : 42
Ticks             : 4910423270
TotalDays         : 0.0056833602662037
TotalHours        : 0.136400646388889
TotalMinutes      : 8.18403878333333
TotalSeconds      : 491.042327
TotalMilliseconds : 491042.327

In fact, despite many attempts over several days, the search never completed. Failures happened after six, seven, or eight minutes, even during the weekend when the service experiences light demand. Using high completeness searches was a deeply unsatisfying experience that doesn’t cast a good light on Microsoft engineering or software testing.

The Microsoft Imperative to Constrain Resource Demand

Microsoft has history in messing around with the Search-UnifiedAuditLog cmdlet in ways that affect production scripts. In September 2023, they changed the way searches worked so that fewer results were returned by default. Microsoft didn’t make any announcement at the time and denied that any change had occurred even though the evidence was clear and obvious that the cmdlet now functioned in a dramatically different way.

It seems to me that Microsoft is a victim of the audit log’s success. When it was first introduced, the audit log ingested data from core workloads like Entra ID, Exchange Online, and SharePoint Online for a relatively small number of events. Eight years later, thousands of different events are ingested from multiple workloads, which increases the resources required to store and process audit events. Another extra demand for resources came when Microsoft had to up the retention period for Purview Audit standard customers from 90 to 180 days. Conserving resources is why the Audit search in the Purview portal (Figure 1) only performs asychronous searches and doesn’t use the Search-UnifiedAuditLog cmdlet.

Microsoft points to the AuditLog Query Graph API as a method for programmatic access to audit data. This is true, but setting up and running AuditLog Query searches takes substantially more effort than running Search-UnifiedAuditLog does, even using the Microsoft Graph PowerShell SDK cmdlets to interact with the API. It’s one thing for Microsoft to switch the Audit search solution in the Purview portal to use the Graph API; it’s quite another to ask customers to upgrade all their PowerShell scripts to replace Search-UnifiedAuditLog. Making this suggestion in the message center notification displays a callous lack of appreciation about how paying customers use Microsoft software.

A Problematic and Concerning Change

The lack of robustness in high completeness searches is nothing but problematic. If you can’t rely on searches completing, you can’t include search processing in scripts. Although running interactive synchronous searches obviously takes more resources, it’s how paying customers extract value from the audit log.

Changing audit searches to high completeness is bad. It might save Microsoft some computing resources, it will impact production processes by forcing Microsoft 365 tenants to use unreliable and fallible methods to access what is, after all, their audit data. Microsoft should leave well enough alone and fix high completeness to make it an optional, slow, but (when fixed) dependable alternative for audit log searches.

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.

Outlook Classic. OWA, and the New Outlook All Get the Org Explorer

Now that we’ve all recovered from the news about the retirement of Viva Goals, a possibly more important change in the world of Viva is the removal of the requirement for a Viva Suite license for access to the Org Explorer feature in Outlook (Figure 1). Microsoft introduced the need for potential Org Explorer users to have a Viva Suite license in February 2023 after originally saying that a Microsoft 365 E3 or E5 license was sufficient.

According to MC939925 (last updated 5 December 2024), rollout of Org Explorer to Outlook users will start in mid-January 2025 and complete by mid-April 2025. The Org Explorer is available for Outlook classic, OWA, and the new Outlook for Windows. Microsoft 365 roadmap item 421191 says that the feature is available to all Microsoft 365 commercial customers, which implies that anyone with a paid-for Microsoft 365 license can use the Org Explorer.

The Need for Directory Sanity

I never understood why Microsoft decided that it was a good idea to license the Org Explorer as a premium Viva feature. The explorer reveals the same kind of information that’s shown by the Microsoft 365 user profile card (without the ability to add custom properties to what’s displayed about users).

It seems like the folks who put together the Viva licensing strategy cast around to find features they could include to justify premium pricing and decided that the Org Explorer was a good fit. It’s yet another of the Microsoft 365 licensing oddities, like demanding an E5 license to add a default retention or sensitivity label to SharePoint document libraries. I had a Viva Suite license at one point, which is how I tested access to the Org Explorer, but after losing that license, I never noticed that the Org Explorer was no longer available in Outlook, which summarized the value I received from the feature.

Even though I might not have discovered much value in the Org Explorer, I think it’s fair to say that those working in large enterprises, especially when offices are distributed and/or multinational, might consider the Explorer to be a useful tool. Like user profile cards, the usefulness of something like the Explorer is highly dependent on the accuracy of the information stored in Entra ID. For instance, if reporting relationships (managers and direct reports) are not maintained in Entra ID, it’s impossible for a tool like the Org Explorer to build a coherent view of the organizational structure.

Some organizations prefer to store reporting relationships in HR databases and don’t synchronize this information with Entra ID. In such a situation, the view of the organization constructed by the Org Explorer is unlikely to be helpful or accurate.

Outlook’s Toggle into the Future

Speaking of Outlook classic, in MC949965 (December 6, 2024), Microsoft says that in April 2026, they will “toggle” enterprise users of Outlook classic to use the new Outlook for Windows. Fortunately, users will be able to recognize Microsoft’s mistake and immediately switch back if they choose. Conditions that will prevent automatic toggling include:

• Tenants hide the switching toggle. Hiding the toggle is the easiest way to stop Microsoft automatically moving Outlook classic clients to the new Outlook.
• Tenants choose an admin-driven migration.
• Outlook accesses on-premises mailboxes.

Microsoft wants to give users the opportunity to try the new Outlook, something that might be better appreciated if the client worked better than it does now. New features like pinning and snoozing messages might be appreciated by some, but I suspect that many in the Outlook community don’t care too much about these things.

Still, who knows what might transpire between now and fifteen months’ time? All the lingering issues that stop people switching now might be solved and everyone will be happy to adopt the new client before Microsoft support for the classic client ceases in 2029.

Change Keeps on Happening

Product retirements, licensing changes, and client upgrades are just part and parcel of Microsoft 365 life. It’s hard to keep track of everything that happens. Even we have a hard time, and we’ve been tracking the ins and outs of change across Office 365 and Microsoft 365 since 2014.

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.

Code Replacement Deadline for Exchange Legacy Tokens Approaching

In May 2024, I wrote about the upcoming change for the authentication method used by Outlook add-ins to embrace a technology called Nested App Authentication (NAA), which is used by ISVs and other developers to obtain access tokens to interact with Exchange through the Outlook REST API or Exchange Web Services (EWS).

Microsoft originally wanted to disable legacy Exchange tokens in October 2024. As tends to be the nature of these projects, customers needed some extra time. However, we’re now on the glidepath to complete disablement for legacy Exchange tokens across Microsoft 365 and Microsoft plans to turn off Exchange legacy tokens for all tenants in February 2025. The exact timing for when a client ceases to support legacy Exchange tokens depends on the Office channel in use (see the timeline for the different Office channels).

What Happens in February 2025

After February 2025, tenants can reenable Exchange legacy tenants using PowerShell. This action grants access until June 2025. At that point, Microsoft will disable Exchange legacy tokens again and tenants will only be able to reenable tokens through an appeal process. If granted, the tenants can use legacy Exchange tokens until Microsoft finally removes the functionality from Microsoft 365 in October 2025. That seems like a long time away, but given the effort required to find and deploy replacement add-ins to Outlook classic clients, tenants need to be in control of the process before the first phase of token disablement happens.

Although Microsoft is going through its normal process of publishing documentation, issuing message center notifications, and so on, one wonders if the message about removing support for Exchange legacy tokens is getting through. This is important because this change will eventually cause Outlook or OWA add-ins to stop working for many Outlook users if action is not taken.

Knowing What Add-Ins Are in Use

Microsoft has collated information about the Outlook add-ins known to be in use inside Microsoft 365. That information is available in a downloadable Excel worksheet (Figure 1). Additional reporting is expected in early 2025.

The first thing to do is to download and analyze the worksheet to identify what add-ins are in use within the tenant and who developed the add-in. At this stage, you must run several cmdlets (see instructions here) to discover the add-ins deployed in your tenant.

Often the author will be an ISV like SAP who understands the problem and has already created a replacement add-in based on NAA, the new way for add-ins to authenticate and receive access tokens from Entra ID. Some other add-ins might be authored by in-house developers, in which case the responsibility for updating the add-in code lies with the tenant. Microsoft’s documentation highlights some API calls that developers need to pay special attention to because they indicate the use of legacy Exchange tokens.

Some add-ins might have been developed by a company that’s now out of business. In these cases, the add-in will cease working once Microsoft disables legacy Exchange tokens and there’s no path forward except to find (or develop) a replacement add-in.

It Would Have Been Better to Start Earlier

Change is never easy, especially when it involves code that’s installed and run in a client like Outlook classic that’s been around for a very long time. There’s no easy workaround either when the problem involves a fundamental change in authentication and access that must be addressed in a code update.

Given the timeline, the important thing is to start the assessment process as quickly as possible. Identifying the set of add-ins in active use is critical, as is knowing where the necessary code updates will come from. After that it’s a mere matter of deploying the updates to individual workstations, which is always the easiest part of projects.

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.

Viva Goals Retirement To Happen on December 31, 2025

Viva Goals is an implementation of the Objections and Key Results (OKR) methodology to allow organizations to define and measure progress against goals (the OKRs) set at the organization or team level. Goals wasn’t part of the original launch for Microsoft’s Viva employee engagement suite in February 2021. As part of its work to extend the Viva suite Microsoft acquired Ally.io in October 2021. The technology was subsequently rebranded as Viva Goals and reached general availability in August 2022.

Microsoft’s decision to retire Viva Goals came like a bolt from the blue. The first public indicator emerged when Microsoft published MC949603 in the Microsoft 365 admin center on December 5 along with a companion explanatory article to let customers know that Microsoft ceased development for Viva Goals on December 5, 2024 and will retire the product on December 31, 2025. Microsoft also said that no prospect exists to extend access to Viva Goals past the retirement date.

Looking back, the resignation of Ally.io founder Vetri Vellore from Microsoft in December 2023 might be seen as an early indicator that things weren’t going so well with Viva Goals. Vellore is now leading the development of Rhythms.ai, an “AI-powered operating system for high-performing teams.” It’s not unusual for founders of acquired companies to depart after their retention agreement expires, and Vellore departing to set up another startup fits the pattern. However, it probably didn’t help. Losing leadership is never good for a struggling product.

Why Forced the Viva Goals Retirement?

When it announces decisions, Microsoft often stresses its use of telemetry acquired from user activity to inform those who make the decisions. In this case, Microsoft says that “While some customers have recognized value, overall adoption and usage of Viva Goals across the Viva Suite customer base has not grown. Microsoft has been unable to reach the scale and impact needed to continue further investment.” In other words, some customers like Viva Goals but not enough have opted to use it to warrant further development.

Given the scale that Microsoft 365 runs at, it’s unsurprising that Microsoft has high hopes for new products. If products don’t attract substantial customer interest, the potential for failure and retirement always exists. Introducing OKRs into an organization is not like launching an application like Planner. According to some successful practitioners, executive buy-in and leadership is needed to drive the adoption of the methodology. Support from the top of the organization can’t be half-hearted or inconsistent. It’s got to be fully committed and ongoing, and while some customers are enthusiastic about OKRs, it’s obvious that most didn’t view Viva Goals as an important part of their cloud infrastructure.

The most recent usage number revealed by Microsoft was that the Viva Suite had 35 million monthly active users (July 2023). However, Microsoft did not specify usage data for individual products within the suite. The situation is further complicated because Viva Engage (Yammer) components like the Q&A app show up in Teams and might accrue some usage through that route. Another example of how Viva Engage embraces Teams in a way that should drive usage is the support for storylines in Teams chat announced at Ignite 2024 and due for availability in early 2025.

The Second Viva Element to Fall

Viva Goals is the second element of the Viva Suite to be axed following another surprise decision to retire Viva Topics earlier this year. In the case of Viva Topics, Microsoft pointed to Microsoft 365 Copilot as a replacement. Since the announcement, Microsoft has delivered features like custom agents to allow tenants to develop their own form of knowledge infrastructure, albeit for much higher license costs.

The path forward for customers who use Viva Goals is less obvious. In the FAQ for the Viva Goals retirement, Microsoft says that they are “exploring third-party solutions and partnerships to facilitate a smoother transition.” It seems like a lot of work needs to happen between now and December 2025 to create migration tools to export data from Viva Goals to other platforms. We’ll have to see how the transition unfolds.

More Disruption in Viva?

The retirement of two products from the Viva suite might cause some to think that it’s not worthwhile to invest any more time into Viva products. That’s an understandable feeling. Given the way that Microsoft has demonstrated absolute ruthlessness in cutting underperforming products from its portfolio, the future of any Viva product is certainly something to consider. The current line-up is:

• Viva Connections
• Viva Engage
• Viva Amplify
• Viva Pulse
• Viva Glint
• Viva Insights
• Viva Learning

Seven products seem like too many. It’s certainly confusing at times to understand what each product does. It will be interesting to see if Microsoft trims the line-up further in 2025.

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 monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Unified Microsoft 365 Video Start Page Rolling Out Now

Microsoft’s November 26 announcement that they plan to combine Clipchamp and Stream “into a single, streamlined video solution that harnesses the strength and usage of both platforms” is a development that marks the natural conclusion of a process that started with the Clipchamp acquisition (September 2021). The unification will happen under the Clipchamp brand, starting with the launch of a new Microsoft 365 video start page (Microsoft 365 roadmap item 468289). The new page (Figure 1) is already shown in tenants when users select the Stream or Clipchamp options from the Microsoft 365 menu.

The Many Steps to Microsoft 365 Video Unification

As noted above, the unification marks the completion of work that’s been ongoing for several years. Stream migrated video content from the original Office 365 Video portal to its own Azure-based storage. Stream then made the leap to move its files to the SharePoint Online and OneDrive for Business (ODSP) platform, a process that completed earlier this year.

Recent work on Stream has focused on building out player capabilities rather than video editing. Stream can trim a video by hiding parts of a file from user view, but it can’t handle the kind of sophisticated video production tasks that Clipchamp specializes in and are found in competing products like Camtasia.

While the Stream migration to ODSP was ongoing, Microsoft absorbed Clipchamp. Although they haven’t described the technical details of the work done to allow Clipchamp to embrace and use the Microsoft 365 framework, anyone with any knowledge of how Microsoft 365 works can imagine the challenges that flowed after Microsoft’s July 2023 announcement that Microsoft 365 tenants would get the application.

Using Entra ID for authentication and role assignments, supporting multifactor authentication, and moving storage to ODSP are three obvious work items. However, the work to allow users to access Clipchamp and store video files is only the tip of the iceberg and lots of detailed work happened under the surface to ensure that Clipchamp works smoothly within Microsoft 365. At the same time, Clipchamp Consumer continues and needs to be maintained.

Coming Soon

Microsoft promises that the unified offering will continue to deliver more than video editing. For instance, the announcement discusses the ability to share a clip from within a video. Essentially, this means that a user can select a start and end time for a clip and send that detail to other users to allow the recipients to play the video from a precise location for a specified time. The advantage cited is that this removes the need to edit the video and store a file for short (or long) clips.

Microsoft also says that the lightweight video recorder currently available in Stream will be able to call Clipchamp to edit the output. This is referred to as advanced editing from camera and is due for release in January 2025.

Finally, Microsoft notes that the ability to capture and insert video content is available in Outlook. Well, it is in the new Outlook for Windows and OWA but not in Outlook classic. Perhaps the folks who continue to use Outlook classic are content to communicate using words rather than a video clip. As Figure 2 shows, filming a clip is invoked using the Record button (which becomes available when positioned in the message body.

The video clip sent in the email is captured in a Loop Stream component stored and shared from the RecordingsVideo Clips folder in the sender’s OneDrive for Business account. This is the same folder used to hold video clips recorded in Loop pages or other components. If a recipient uses Outlook classic, they can launch the Stream player to view the file.

Microsoft 365 Video Unification is Positive

It didn’t make sense to have two video solutions within Microsoft 365. Unifying around a single brand makes perfect sense. Although it was originally launched for consumers, the Stream brand never worked in that market. Bringing things together under Clipchamp removes confusion and clarifies how video is managed inside Microsoft 365. It’s a positive development.

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 monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Analyze the Audit Events for a User Over a Single Day

I’m speaking about decoding the Microsoft 365 audit log at the ESPC conference in Stockholm, Sweden today. As part of the preparation for the session, I wanted to create a demo to highlight some of the challenges of interpreting audit records to attendees. I have many examples of PowerShell scripts that perform different tasks, like finding the last accessed date for documents stored in SharePoint Online. These scripts work well and solve problems, but they don’t shine a light onto the biggest single issue with audit log data. That issue is the maddening inconsistency found in the audit data payload contained in audit records.

The Two Parts of Audit Log Records

Audit records have two parts. The first is a consistent set of properties that must be respected by workloads when they generate audit records. These properties include the unique identity (GUID) for the record, a timestamp, the name of the user or process who performed an action, and the name of the action. The second part is the audit payload, a JSON structure contained in the AuditData property. Microsoft 365 workloads like Exchange Online and SharePoint Online control what they insert into the audit payload for their events, and no consistency and sometimes no reason governs what turns up in audit payloads.

The lack of consistency means that anyone attempting to interpret audit data must figure out what the audit payload contains and put it into context with what you know about the action captured by the event. The content differs from Exchange Online to SharePoint Online to Teams to Planner to Entra ID. The lack of consistency and the obvious errors in audit data points to poor control and attention to detail by engineering groups, both the team responsible for the audit log and the teams responsible for generating workload events.

Investigating User Actions for a Day

To illustrate the problem, I decided to create a script to report details of all actions taken by an individual user over a single day. I developed the script by fetching the audit records (about 2,200) logged for me on 27 November 2024 and reporting what I found. I stripped UserLoggedIn events from the set because of the number (946) of sign-ins to different applications from multiple devices. Most of the sign-ins are silent and result from the renewal of an access token. Figure 1 shows what the output report looks like.

The set of actions spanned interactions with multiple workloads for user activities like creating and updating documents, sending messages via Exchange and Teams, and reading a Planner task list. It also included some administrative actions like conducting an eDiscovery search, running some Exchange PowerShell cmdlets, and so on. No set of audit events for any single user will be 100% representative of what you’ll find across Microsoft 365, but I am confident that the results found in this set of audit records demonstrates the problem.

The script unpacks the audit payload for each event to extract a small set of properties for the report. A large Switch statement is used to interpret each type of event. It would be practically impossible to include every possible event, so I concentrated on common events and some that illustrate the problem.

In some cases, some of the properties contained in compliance audit records are obscured through Base64 encoding. Unfortunately, the encoding is resistant to PowerShell decoding unless you remove spurious characters at the end of the string. For example, here’s how the script handles events for the Get-ComplianceSearch action (retrieve details of a content search):

"Get-ComplianceSearch" {
   $Action = 'Compliance search retrieved'
   If ($AuditData.Parameters -eq '-ResultSize "Unlimited"' ) {
      $Object = "All results"
    } Else {
      $Object = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String( $AuditData.Parameters.Split('"')[1].SubString(0,32)))
    }
      $Location = $AuditData.Workload
      $Workload = 'eDiscovery'
   }

Some audit events contain details for multiple events. This is done for very good reason as the actions being captured are very common and would otherwise flood the audit log with data. The MailItemsAccessed event is a good example. This event is now available to Purview Audit Standard (Office 365 E3) customers and captures details of email items accessed by a user. The audit payload for a MailItemsAccessed event can contain details of 20 or 30 messages. MailItemsAccessed events can also contain details of sync actions (see this article and the associated script for details).

You can download the script to generate a report of user audit events for a day from GitHub. It’s easy to add processing for other events if you wish.

Consistency Would Make Administration Easier

The bottom line is that interpreting audit events takes a lot of knowledge and persistence. Like anything else in technology, the combination brings you a long way. It’s regrettable that Microsoft has allowed a situation to develop where nearly 2,000-odd audit events might need different processing to extract real value. Life would be so much easier if audit data was more consistent.

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.