
Hey everyone!
Firstly, thank you Craig Dalrymple for sharing this one!
From the release of Veeam Backup for Microsoft 365 v6a, Veeam have supported using the new Microsoft Teams APIs to protect conversation data – not full support yet, but that’s another story! However, Microsoft deemed these APIs as ‘protected’ and therefore, to gain access to them, you had to submit the form located here: https://aka.ms/teamsgraph/requestaccess
There are quite a few posts in the community & R&D forums regarding how painful this process is.
Thankfully, enough noise was generated that Microsoft have changed the process.
Now, Microsoft are stating that you don’t need to complete this form for API request access, provided you meet the following requirements:
- Use App Registrations, which Veeam already does for the VB365 application
- Enable your application for Metered API consumption by associating it with an Azure subscription, details here: https://learn.microsoft.com/en-gb/graph/metered-api-setup?tabs=azurecloudshell

I decided to fire this up myself and take the new process for a test drive, using the handy Azure Shell.
To start with, I wanted to create a dedicated resource group for my billing, so I ran the below:
az group create --name "VB365_Metered_APIs" --location uksouth |
Note the following message from Microsoft regarding resource group creation:
Resource group names can only include alphanumeric, underscore, parentheses, hyphen, period (except at end), and Unicode characters that match the allowed characters.
Then, with my resource group created, I needed to run the following command:
az resource create --resource-group VB365_Metered_APIs --name VB365APIBilling --resource-type Microsoft.GraphServices/accounts --properties "{""appId"": ""appIDGUID""}" --location Global --subscription subscriptionGUID |
Whilst the resource group (VB365_Metered_APIs in this example) and resource (VB365APIBilling) names will be unique to your own configurations, the following alternations also need to be:
- appIDGUID needs to be substituted with your App Registration’s GUID
- subscriptionGUID needs to be substituted with your GUID of the subscription you wish to bill the metered API consumption against.
We can fetch these easily via azure shell by doing the following:
appIDGUID
Here we want to find the application ID used by VB365, if you want to return the entire list you can run:
az ad app list |
If you know the name of your application, you can run the following command:
az ad app list --display-name "Application Name" |
For either scenario, look for “appID”: “appIDGUID” in the output.
It might be easier if you use the following command:
az ad app list --display-name "Application Name" --out table |
Finally, you might prefer to get the Application ID from VB365, to do so, edit your M365 organisation within VB365, and when you reach the Azure AD Application section, select “Use an existing Azure AD application”, and grab the Application ID from there. Details here.
SubscriptionGUID
If you run the following command, you’ll get a list of all your tenant’s subscriptions:
az account subscription list |
In the output, look for “subscriptionID”: “subscriptionGUID”
then extract the GUID from your output, ready for your command.
If you know the name of your subscription, you might find it easier to run:
az account subscription list --subscription "Subscription Name" |
Likewise you might find the output easier if you append the “–out table” formatting to the output such as:
az account subscription list --out table |
or
az account subscription list --subscription "Subscription Name" --out table |
Final Notes
With everything pieced together and the command executed, you should be good to start backing up your Teams Chats, without the lengthy manual process of the forms.
As a reminder, it doesn’t matter if you do everything in here, if you haven’t enabled Teams chats processing in the first place, the details of how to do so are located on the Veeam KB article here.
And to close, please remember that as these API calls are metered, as long as you keep paying the bill, Microsoft won’t care how much you consume. The responsible consumption of these APIs is on you and your organisation to monitor and consume carefully. Treat this with the same care you’d take when handling Azure/AWS/GCP/any metered infinite consumption model.