Admin Settings API to Control Usage Reports Data Gets an Update

If you don’t follow the sometimes-anarchic world of the Microsoft Graph, message center notification MC859853 (13 August 2024) might have passed you by without comment. However, given the importance of reporting usage data to understand the activity level within tenants, this is a significant change.

The option to anonymize user information like display names in usage reports generated from the Microsoft Graph has existed since 2020. The control for the option is under Reports in the Org Settings section of the Microsoft 365 admin center and its purpose is to protect the privacy of users. The control affects all access to usage data via the Graph, including reports generated using PowerShell, such as the Teams and Groups Activity Report. In fact, if you choose to obfuscate user data, reports lose much of their value and can make it impossible to derive comparisons between different forms of usage data. For instance, the script to analyze use of different Microsoft 365 workloads by individual accounts to determine who could best use Copilot for Microsoft 365 licenses depends on being able to match user principal names.

Programmatic Access to Set the Privacy Control for Usage Reports Data

It’s useful for programs and scripts to be able to turn the privacy control off to fetch usage data and back on again when finished. Until now, programmatic access to control the privacy setting for usage reports existed in the beta adminReportSettings Graph API. What’s changed is that the API is now generally available and therefore available through the V1.0 Graph endpoint. In the past, a script might have done something like this to check if the privacy setting was on or off:

$Uri = "https://graph.microsoft.com/beta/admin/reportSettings"
$Data = Invoke-MgGraphRequest -Method Get -Uri $Uri
Write-Host ("The current report privacy setting is {0}" -f $Data.displayConcealedNames)
The current report privacy setting is False

Now that the API is generally available and fully supported, the URI is https://graph.microsoft.com/V1.0/admin/reportSettings. For instance, to update the privacy setting to set it on, you’d do:

$Uri = "https://graph.microsoft.com/V1.0/admin/reportSettings"
$Settings = @{}
$Settings.Add("displayConcealedNames","true")
Invoke-MgGraphRequest -Uri $Uri -Method Patch -Body $Settings

The Microsoft Graph PowerShell SDK has just had a refresh to V2.22 but the SDK cmdlets haven’t yet caught up with the change and remain using the beta endpoint. This means that you should use Get-MgBetaAdminReportSetting to fetch values and Update-MgBetaAdminReportSetting to switch the control from on to off or vice versa.

To update the privacy control, the signed-in account must hold the global administrator role and the app used must have consent for the ReportSettings.Read.All permission.

Backup Restore Module in V2.22 of the Microsoft Graph PowerShell SDK

One of the notable things about V2.22 of the Microsoft Graph PowerShell SDK is the appearance of a new beta module for Microsoft 365 Backup (backup and restore operations). To list the commands in the module, run Get-Command:

Get-Command -Module Microsoft.graph.beta.backuprestore

Use of the cmdlets requires consent for the BackupRestore-Control.Read.All permission (Figure 1).

Despite having the permission and an active Microsoft 365 Backup schedule in place for SharePoint Online, OneDrive for Business, and Exchange Online, all attempts to use the cmdlets met with an internal error. Oh well, Microsoft 365 backup is only just generally available, and this is a beta module. Things are expected to go wrong. It’s just another opportunity for improvement within the Microsoft 365 ecosystem.

Graph Keeps On Growing

Being able to control usage report data privacy and Microsoft 365 Backup through Graph APIs are two examples of how people might not have considered using the Graph to automate common administrative scenarios. It’s proof of the growing influence of the Graph, and underlines why Microsoft 365 tenant administrators need to become Graph literate.

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

The Evolution of Microsoft 365 Backup to its Current Preview Status

Paul Robichaux, a longstanding MVP and someone who knows much more than I do about backup technologies, wrote an interesting review of the public preview of Microsoft 365 Backup for Practical365.com. I don’t need to dive into the details of what Paul covered about the mechanisms used by Microsoft 365 Backup to protect SharePoint Online, OneDrive for Business, and Exchange Online data. Instead, I decided to focus on how restore operations work. I did this on the basis that it’s straightforward for a backup product to stream data from a repository to create a copy of one form or another. The trick is to be able to restore copied data to the right place at the right time in the right way.

For background, I’ve been tracking the progress of Microsoft 365 Backup for several years, including discussions with the Microsoft engineers who built the product. When Microsoft began to discuss the product in public, I concluded that it was something I needed to test and potentially use over the longer term to protect my tenant’s data.

Until now, I have largely eschewed backups for Microsoft 365 and relied on native data protection (for Exchange Online) and retention policies. I consider many of the arguments advanced by companies selling backup solutions to be firmly rooted in FUD, especially when it comes to Teams. Unsurprisingly, because Teams is the most difficult Microsoft 365 workload to backup (and even harder to restore), Microsoft hasn’t included it in its set of target workloads.

When Microsoft launched the preview of Microsoft 365 Backup, I configured backup policies for all workloads and opted to protect the most active (and probably) valuable sites, accounts, and mailboxes in the tenant, including the site holding the source files for the Office 365 for IT Pros eBook. Backups have progressed since early January. Apart from adding extra mailboxes and accounts to the backup policies, I haven’t had to do anything since the original configuration.

Restoring Microsoft 365 Data

The big selling point for Microsoft 365 Backup is that it makes it fast and easy to restore data. The data for backups is stored in the Microsoft Cloud and is almost instantly accessible, or so the story goes. Backup professionals don’t like all their eggs stored in one cloud basket and don’t consider Microsoft 365 Backup to be a true backup. However, having everything in the Microsoft cloud makes backup and restore operations much faster than if the data must transit the internet to storage in a backup vendor’s datacenter.

There’s no doubt that Microsoft created a simple and easy to use UI for backup. The downside is that there’s no log to help you understand what happened during a restore or more importantly, where problems might have been met. Before beginning, it’s wise to read the latest set of limitations documented by Microsoft. Apart from anything else, you might discover that you must do something before a restore is possible, such as removing in-place holds from Exchange mailboxes. The number of documented limitations is likely to decrease as Microsoft develops the product from its current preview statis to a point where Microsoft 365 Backup is generally available.

You can learn the details of restore operations from Microsoft’s documentation. Creating a restoration task follows much the same path for all workloads:

• Select the workload.
• Select the protected locations (site, account, or mailbox) to restore.
• Select the restore point (Figure 1).
• Confirm everything and launch the restoration task.
• Wait for the restoration task to complete.

My experience is that Exchange Online restores are quicker than SharePoint Online or OneDrive for Business. That’s likely due to the way Exchange uses an existing copy-on-write mechanism to tag items. In all tests, Exchange restored data within a few minutes. As a quick and simple test to ensure that the data was restored, I used PowerShell to note the contents of important folders before and after a restore.

For example, here are the folder statistics at the time that I wanted to restore to:

Get-EXOMailboxFolderStatistics -Identity "James.Ryan@office365itpros.com" | where-object {$_.ItemsInFolder -gt 0 -and $_.Name -in $Folders} | Format-Table Name, ItemsInFolder, FolderSize

Name          ItemsInFolder FolderSize
----          ------------- ----------
Deleted Items             0 0 B (0 bytes)
Inbox                  1038 248.5 MB (260,572,313 bytes)
Sent Items               19 794.1 KB (813,182 bytes)
Deletions                 6 3.689 MB (3,868,185 bytes)
Purges                    1 1.904 KB (1,950 bytes)

I then removed some items from the Inbox and emptied the Deleted Items folder. The increased number of items in the Deletions folder matches the number of items removed from the Inbox and those emptied from Deleted Items (5).

Name          ItemsInFolder FolderSize
----          ------------- ----------
Deleted Items             0 0 B (0 bytes)
Inbox                  1033 247 MB (258,973,507 bytes)
Sent Items               19 794.1 KB (813,182 bytes)
Deletions                11 5.214 MB (5,467,162 bytes)
Purges                    1 1.904 KB (1,950 bytes)

I then created a restore task using the restore point closest to the time when I first noted the folder contents. When the restore finishes, I checked the data reported by Exchange. We can see that it roughly matches what was there at the start. One item from Sent Items was deleted, so it’s in Deleted Items. This emphasizes that Exchange Online uses a roll forward mechanism for restore, meaning that items that aren’t affected (a refile to another folder doesn’t affect the item status, a deletion does) are left intact.

Name          ItemsInFolder FolderSize
----          ------------- ----------
Deleted Items             1 19.28 KB (19,745 bytes)
Inbox                  1038 248.5 MB (260,572,377 bytes)
Sent Items               18 774.9 KB (793,459 bytes)
Deletions                 6 3.689 MB (3,868,185 bytes)
Purges                    1 1.904 KB (1,950 bytes)

Naturally, this is an imperfect way to validate restore operations. A visual check of mailbox contents confirmed that everything that I expected to be there was in place. Exchange Online logs audit records for the New-MailboxEnhancedRestoreBatch and New-MigrationBatch operations when it starts a restoration task. The details of the audit event only tell you that a restore began for a user called “NT AUTHORITY\\SYSTEM (w3wp).” Some of the data logged in the events might be useful to a Microsoft support representative, but the information isn’t detailed enough to help a tenant administrator understand what happened.

Happy that I could restore mailboxes, I went ahead to try to restore data for a SharePoint site.

Restoring SharePoint Online

Both SharePoint Online and OneDrive for Business use a roll back process for restores. In other words, you decide what restore point to use, and Microsoft 365 Backup rolls back the site or account to have the content stored at that time. Restores can be to the same site or to a new site. If you restore to the same site, the possibility currently exists that people working in the site might have their work overwritten. Microsoft plans to lock sites against changes to avoid this issue in the future. Exchange uses a roll-forward process, meaning that unchanged items since the chosen restore point are unaffected and only changed or deleted items are brought back. In any case, my experience with SharePoint restores didn’t go so well.

I added a bunch of files to a site and then tried to roll back to a point beforehand. The idea was to replicate infection by malware when you need to restore a site to the last good backup before the malware arrived. SharePoint accepted the restore task and about fifty minutes later politely failed. Nothing happened to the restore destination and the detail available about what happened to cause the restoration task to fail was non-existent (Figure 2).

Many attempts to restore the site failed and the last restoration task failed after nearly three hours (the second task listed in Figure 3). SharePoint Online does not log any audit records for administrators to check nor is any other log available to consult to discover why the task failed. Despite rereading the documentation several times and checking all the settings, I could make no progress. Perhaps it’s just me, but I failed in my initial attempts to successfully restore SharePoint Online sites or OneDrive for Business accounts.

Without Microsoft 365 Backup generating a log file or revealing more details about failure symptoms it’s hard to diagnose what’s happening. I put the problem to Microsoft and learned that the problem is due to the holds applied by retention policies. This limitation is documented for OneDrive and mailboxes but not for sites. For now, the solution is to restore files to a new site. This works and restoring files to a different site allows them to be copied to the original site as necessary. However, it’s not quite the smooth recovery operation that I anticipated, even in a preview product.

My biggest concern is that the holds imposed by retention policies block restoration tasks. When things go wrong, administrators want to restore sites or accounts back to good health as quickly as possible. Speed, after all, is the promise extended by Microsoft 365 Backup. Altering settings for Microsoft 365 retention policies to remove holds on sites, including the potential need to adjust adaptive scopes, is not speedy. It can take days before changes are fully respected by SharePoint Online. How then are fast restores possible?

Remember It’s a Preview

Microsoft 365 Backup is a preview solution, but it’s a paid-for preview and I expected what appears to be a straightforward restore request to happen without trauma. After talking to Microsoft, I think they understand that problems exist that must be sorted out before the product reaches general availability. As noted above, these issues include speed of restore, faster detection of problems in restoration tasks, better error handling and logging, and much more elegant handling of sites under control of retention policies.

Microsoft 365 Backup for SharePoint, OneDrive, and Exchange

A year ago, Microsoft announced their intention to enter the backup market with a product to backup Exchange Online and SharePoint Online data. Roll on to Ignite 2023, and Microsoft announced that a paid public preview will begin later this year (probably in December after the U.S. Thanksgiving holiday period.) I expect general availability will follow in 2024. According to the SharePoint Premium announcement, the Microsoft 365 Archive product is now available.

The ISV Backup Conundrum

Backup solutions for Microsoft 365 is a market with many third-party (ISV) offerings. Backing up SharePoint Online sites and OneDrive for Business accounts (documents) and Exchange Online mailboxes are well-known challenges that ISVs know inside out. Microsoft’s decision to retire Exchange Web Service (EWS) in October 2026 complicates matters because many ISVs use EWS to read mailbox data. The replacement Graph APIs are not available yet.

However, Microsoft has made the APIs underpinning Microsoft 365 Backup available to ISVs. Microsoft always tries to line up a bunch of ISVs to support product announcements. It’s a way of proving to customers that the initiative is worthwhile. In this case, it was noticeable that many of the heavy hitters in the Microsoft 365 backup space are cited: Veeam, AvePoint, CommVault, Veritas, Rubrik, and Cohesity. However, that list is not exhaustive and doesn’t include other well-respected ISV backup vendors, like Quest and Keepit.

Some ISVs might have decided to wait for the APIs to mature before switching product direction or have concluded that their current solutions work well enough for now. It might also be the case that customers prefer not to put all their backup eggs into the Microsoft basket and want to maintain separate copies outside the Microsoft datacenter boundary. This isn’t possible using the Microsoft backup APIs.

Pay for Backup with an Azure Subscription

No matter if you use the Microsoft 365 Backup product or an ISV solution based on the Microsoft 365 Backup API, you still must have an Azure subscription to pay for processing backup data. According to the pricing information released by Microsoft, your subscription is charged $0.15 per month for every gigabyte or partial gigabyte processed (protected) by the service. The same price applies to Exchange Online, SharePoint Online, and OneDrive for Business content.

The public preview of Microsoft 365 Backup is a paid preview. If you want to kick the tires to see how backup (and more importantly, restore) works as smoothly and quickly as Microsoft predicts, you need an Azure subscription with a credit card that’s linked to Syntex pay-as-you-go. Linking an Azure subscription isn’t a difficult process as it literally takes a few clicks through the Setup section of the Microsoft 365 admin center (Figure 1).

Before starting, consider creating a new resource group to handle backup operations in your Azure subscription. It will make tracking costs easier. I created the “Backup” resource group for this purpose so it’ll be ready to go when I start to use Microsoft 365 backup.

Microsoft 365 Backup Not Yet a Complete Solution

It’s worth pointing out that Microsoft is starting with the easiest data to backup and that the more complex elements of Microsoft 365 are not included, like Teams, Planner, and Loop. Teams remains the most difficult Microsoft 365 app to backup because of the number of connections it has with other parts of the ecosystem and the lack of API support. Planner has never had a backup API, but it’s possible to read and write Planner data with Graph APIs (here’s an example of reporting Planner tasks for all plans in a tenant). The Loop app (now generally available) uses Syntex repository services to store its data. Although Syntex repository services is based on SharePoint Online, its data doesn’t show up as SharePoint Online sites, so I don’t believe that it is covered by Microsoft 365 backup. Loop components used in Teams channels, chats, and Outlook are stored in SharePoint Online and OneDrive for Business and are therefore covered.

Microsoft will doubtless grapple with and solve some or all of these challenges in the future to create a backup solution that can process the data generated by a complete Microsoft 365 tenant. The approach of keeping data within the tenant (but hidden and inaccessible unless needed for restore) offers many advantages, not least being speed of backup and especially restore operations. But we need more knowledge about how Microsoft 365 backup works in production before arriving at a measured conclusion. The paid preview should answer many questions.

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.

Microsoft Enters a Completive Microsoft 365 Backup Market

One of the big announcements at the Microsoft Inspire (partner) conference marked Microsoft’s debut into the Microsoft 365 backup market. At least. It’s an intention to participate in the market with a public preview of a Microsoft 365 Backup product for SharePoint Online, OneDrive for Business, and Exchange Online in the last quarter of 2023. At the same time, Microsoft plans to deliver a public preview of a Microsoft 365 Archive product to move “inactive or ageing” SharePoint Online data from “hot” (online) storage to cold storage. I can’t wait to “automate scaled mass archiving by running PowerShell scripts” to move SharePoint Online files to cold storage.

Seriously, both initiatives are welcome. Microsoft has some unique advantages (and some disadvantages) when it comes to moving data around from Microsoft 365 repositories, and it’s about time that Microsoft took some responsibility for protecting customer data with backups.

The Microsoft Advantage

Microsoft’s advantage over ISV backup partners is twofold. They have instant access to customer data stored in their datacenters and they control the APIs that allow access to the data.

ISV alternatives typically copy information from Exchange Online, SharePoint Online, and OneDrive for Business (and sometimes Teams messages) from their native repositories to their datacenter. Many issues come into play:

• Shipping large quantities of data across the internet from Microsoft’s datacenter network to the ISV’s target datacenter. This process takes time and can be resource intensive, especially for restore operations.
• Lack of suitable APIs to stream large quantities of data from Microsoft to the ISV datacenter. For instance, Exchange Web Services (EWS) is the foundation for many ISV backup solutions for Exchange Online. EWS was never designed for this purpose, but it works. Some ISVs use EWS to copy Teams compliance records and call it a Teams backup. Microsoft wants to move ISVs to use the Teams export API, but that comes with its own complications.

Microsoft 365 Backup doesn’t use another repository. Everything stays inside Microsoft 365, so restores (when necessary) happen extremely quickly, even at massive scale. The idea is that if a Microsoft 365 tenant is compromised by ransomware, it can very quickly switch back to the status that pertained at a point in time before the attack happened. It’s a compelling proposition, especially when integrated into the Microsoft 365 admin center (Figure 1). Of course, it would be even better if the tenant stopped the attack by taking steps such as implementing multi-factor authentication everywhere, but that’s another matter.

Microsoft hasn’t said what licenses or costs are likely to be incurred with Microsoft 365 backup. I imagine that they will charge on a consumption basis, meaning that tenants will pay using an Azure pay as you go subscription based on how much data they process.

The Microsoft Disadvantage

The big disadvantage for Microsoft 365 Backup is that all data remains in Microsoft datacenters. Keeping all your eggs in one (datacenter) basket is not deemed to be a good thing because the remote possibility exists that the datacenter might suffer a catastrophic failure that leads to data loss. I don’t consider this to be something likely to happen, but I understand why companies like to maintain a separate copy of their data at a different location, just in case.

The ISV Play

Microsoft was careful to launch with ISV support. It doesn’t make sense to go to war with ISVs that have been serving Microsoft 365 customers for years. Microsoft has several launch partners that are signed up to use the backup and archive APIs so that “partners can integrate our capabilities into their data management and protection apps. With Microsoft 365 Backup and Microsoft 365 Archive APIs, our partners can uniquely provide a single and seamless experience that protects your data estate, whether inside or outside of Microsoft 365, in combination with our speed and storage innovations.” In other words, ISVs can use the APIs (and pay Microsoft for the privilege) to take advantage of faster backup and restore for Microsoft 365 data. We’ll see how this transpires in terms of costs and how the ISVs adopt Microsoft 365 backup APIs in their solutions.

No Teams Backup and Restore

Microsoft has deliberately targeted the easiest workloads for backup. Emails and documents are relatively easy objects to backup and restore. Microsoft has unfettered access to the data and can tweak APIs to make backup and restore operations easier so their implementation is faster and smarter. However, Microsoft 365 archive does not take on the biggest challenge that exists for backup today, and that’s to deliver seamless backup and restore capabilities for Teams.

Teams borrows from multiple Microsoft 365 and Azure services. It integrates data drawn from multiple sources and applications. This, and the lack of APIs to perform comprehensive backup and restore for Teams, is what creates the challenge. Given that Teams now has over 300 million monthly active users, it’s a pity that Microsoft hasn’t cracked a nut that they are uniquely positioned to take on. Perhaps full Teams backup and restore will come in time.

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.

To Backup Or Not To Backup

I’ve noticed several backup vendors become very excited by the Microsoft Shared Responsibility model for cloud services (Figure 1), mostly because the belief exists that the model supports the need for backups. I’m not sure that this is the case. Like any generic model, interpretations vary with circumstances and it’s impossible to say that the model always applies in all circumstances.

Microsoft Service Agreements and Backups

Another Microsoft document often advanced in support for backups is the Services Agreement for Online Services. While undoubtedly true that the agreement mentions backups three times, two are in the context of closing an account and the need to copy data before closure. The other mention says, “We recommend that you regularly backup Your Content and Data that you store on the Services or store using Third-Party Apps and Services.” At first glance, that sounds conclusive. And then you realize that the recommendation is for Microsoft consumer online services like Outlook.com and OneDrive.com. We therefore conclude that Microsoft recommends consumers to backup their data, which is reasonable advice.

Challenges in Microsoft 365 for Backup Products

The equivalent service agreement document governing Microsoft 365 doesn’t mention backup at all. I think several reasons exist why this is so.

• Microsoft 365 applications include features like Exchange Online native data protection to ensure that data loss does not occur. Some other features, like retention policies and labels, depend on having appropriate licenses (Office 365 E3 and above), and can be used to ensure that important data cannot be removed.
• Although APIs exist to backup some Microsoft 365 apps, the APIs were never created to underpin cloud backup and recovery. For instance, Microsoft created Exchange Web Services (EWS) for programmatic access to mailbox data. EWS was never intended to stream large quantities of mailbox data across the internet.
• Even worse, backup APIs do not exist for the newer cloud-only services like Teams, Planner, Yammer, and Stream. Microsoft can’t recommend backups when no possibility exists to take backups. Some vendors attempt to workaround the lack of APIs by copying compliance records from Exchange Online. This is acceptable if you recognize that the records are incomplete and cannot be restored.
• Backup products often focus on workloads, like Exchange Online or SharePoint Online. This is old-school thinking firmly rooted in the world of on-premises deployments where workload-specific processing is the norm. In the cloud, apps intermingle in a way which doesn’t happen on-premises. This creates a difficulty in restoring data. To achieve a complete point-in-time restore for Teams, for instance, the restore process might have to deal with Teams channel conversations, chats, configuration data, SharePoint Online and OneDrive for Business documents, whiteboards, calendars, attendance reports for meetings, meeting notes, approvals, and a bunch of data belonging to first and third-party apps. Teams is the most complex of any Microsoft 365 app to backup in terms of the web of connections it uses, but it does illustrate the problem faced for restore operations.
• Given the amount of data generated by Microsoft 365 organizations, I wonder if it is possible to restore more than a few accounts should a problem occur. The value from a backup is often best seen in granular recovery operations when you need to restore just a few documents or a couple of mailboxes. Once numbers scale up, the sheer amount of data which needs to be restored creates a real challenge.

Of course, backup vendors do not acquaint potential customers with these inconvenient facts. Instead, too much focus is given to the potential dire consequences of something like a cyberattack (which has happened to Microsoft 365 tenants) without exploring the methods to resist attacks, like enabling multi-factor authentication for all users.

Not Against Backups

I am not against organizations subscribing to third-party backup solutions to protect their Microsoft 365 data. Backups have their place and can be very valuable if you understand the situation and can leverage backup technology to solve a problem for your company. Any considered decision which takes all the facts into account before settling on a course of action is goodness.

What I am against is the lack of honesty which often happens in conversations around the need for backup of Microsoft 365 data. Too much FUD, like the rogue administrator who removes a bunch of data, is used to create the case for backups. It would be better if backup ISVs argued their case based on fact rather than fear. I live in hope.

Last Updated: 2 April 2021

The topic of backups is covered in more detail in the Office 365 for IT Pros eBook. We like to think we take a pragmatic and sensible approach to the topic.