VB365: Changes necessary for Teams backup in version 6a (New API)


Userlevel 7
Badge +13

For me this has been quite surprising news. With beginning of version 6a of Veeam Backup for Microsoft 365, a different API will be used for backup of public Teams channel messages. The current way with EWS is getting deprecated by Microsoft and in the future “Microsoft Graph Export API for Teams” has to be used.

What does this mean for VB365 users?

With version 6a VB365 will no longer by default protect Teams data. In order to still being able to backup public Teams channel messages, you will have register for the “Graph Export API”. This process can take up to two weeks and in addition the usage of the Graph Export API can cause additional costs (by Microsoft).

How do you register for the Graph Export API?

The registration process is described in detail in the following KB article: https://www.veeam.com/kb4322

What costs will be expected?

Unfortunately I can’t really say what costs will be generated by Teams backup. There’s a dedicated page from Microsoft on the licensing/payment but still I’m not sure what we can expect and how the usage is actually billed.

https://docs.microsoft.com/en-us/graph/teams-licenses

I hope we’ll see some more detailed information on this topic in the near future, or anyone else in the community will be able to clear this topic.

What happens if I don’t switch to the new API?

We can expect that after upgrading to 6a and not registering for the new API, VB365 will no longer be able to backup Teams at all.

Failed to process team: <teamname> Invoked API requires Protected API access in application—only context when not using Resource Specific Consent. Visit https://docs.microsoft.com/en—us/graph/teams—protected—apis for more details.. The remote server returned an error: (403) Forbidden.

So if you don’t want to use the new API, you will lose the ability to protect Teams.

What do you think about this?

This topic in general will probably cause us some headache. Not only is the initial process of protecting your data getting more complicated, but also you will need to calculate some additional costs which weren’t there before (and without getting any additional value). I’m also sure more and more APIs will switch to a paid model.

Interestingly Anton @Gostev predicted this almost a year ago in the Veeam R&D Forums Digest:

For Microsoft Office 365 users > many interesting news came from Microsoft Build 2021 but this particular one has caught my eye (search the post for Microsoft Graph Data Connect). As I read it, the Graph API where Microsoft has been adding all missing Office 365 data access capabilities will now be offered as a metered service. The pros of Graph API are that it is a more secure and higher throughput connector. However, it is now turning into pay-for-access API and as I understand, there are no alternative ways to retrieve at least some of the Office 365 data [for example for backup purposes]. I think you can see where this is going: not only you're already paying to put your data into Office 365, but now Microsoft wants to charge for retrieving this data too. Oh well, let's see how this idea turns out for them. I personally think it's a mistake because even if the price is right, it adds the perfect FUD topic for competing platforms to use right at the peak of the mass exodus from on-prem Exchange.


14 comments

Userlevel 7
Badge +20

This was very interesting to read.

Userlevel 7
Badge +20

Thanks for sharing @regnor, I saw this late on Friday night and was going to try and find some time to write this up, but as this is comprehensive, I’m not sure what value I’d add in my own write up anymore! Good work 🙂

 

Working in VB365 projects is going to become more time sensitive, I’ll be having to capture if customers want Teams backups and ensuring that the action to request this API access is called out early enough to not delay a continuous project timeline.

Then there’ll be the existing customers that are used to having Teams backups, that now need to determine the value of them, along with the reconfiguration of those that have previously deployed teams backup, who’ll suddenly find it doesn’t work post-upgrade. This will be the biggest disruption as the v6a release will no doubt trigger a wave of applications as organisations discover this at the same time. I’d love to see Veeam highlight this in the installer to prevent people upgrading then getting stuck for 2+ weeks applying for protected API access.

 

Fully agree with Anton’s comments, and it feels tactical that Microsoft are doing this with Teams first, the product with no on-premises alternative…

 

I completely believe this is the wrong approach by Microsoft and we can only continue to collectively notify Microsoft of this and hope for change… (A Teams boycott could also work I guess, but that’s another topic completely! 😆)

Userlevel 7
Badge +13

Thanks @MicoolPaul 😊

I think the problem will be, that we can't request access to the API before installing/configuring VB365. As you need to fill in the application ID which you'll only get after the initial setup. So you can postpone the go-live for 2 weeks and need to plan accordingly.

For existing customers, and partners supporting those, it's going to be quite some fun. Informing everyone about the planned change, costs and necessary configuration adjustments. 😐

If there was any way of preventing this and any further changes to metered APIs, I would support it. We could take it to the feedback portal, but I think we'll lose this fight...Teams is already so wide spread that Microsoft doesn't need to fear customer loss. Rather the decision will be to abandon Teams Backup at all and rely on other mechanisms.

https://feedbackportal.microsoft.com/feedback

Userlevel 7
Badge +20

I will have to pass this to our Devs as we wrote a custom portal for VBM365 so will need to see how this will affect our clients. Will be interesting to see if there is some rewrite needed for parts of the portal.

Userlevel 5
Badge +4

it adds the perfect FUD topic for competing platforms to use right at the peak of the mass exodus from on-prem Exchange

What are the alternatives to M365? Seems like a monopoly to me (Bad Microsoft from the 90’s)...time for another antitrust suit? This kind of pricing strategy strikes me as supremely arrogant. Or, another way to steer users away from partner solutions like ours. Ugh. 💀

Userlevel 7
Badge +13

@Chris.Childerhose The process for Teams configuration will probably get much more complicated with v6a for your devs 😐

@randyweis There aren't any which offer a equal feature set like M365. You will find some solutions which can replace some parts and are better then Microsoft, but still their cloud offering has most complete package with a very good price. And because of that Microsoft can do what ever they want.

Userlevel 7
Badge +20

@Chris.ChilderhoseThe process for Teams configuration will probably get much more complicated with v6a for your devs 😐

@randyweisThere aren't any which offer a equal feature set like M365. You will find some solutions which can replace some parts and are better then Microsoft, but still their cloud offering has most complete package with a very good price. And because of that Microsoft can do what ever they want.

Oh I am sure it will. 🤣

Userlevel 7
Badge +10

Thank you for this comprehensive share here @regnor 

Userlevel 7
Badge +9

This is comprehensive @regnor , thank you!

Userlevel 7
Badge +20

it adds the perfect FUD topic for competing platforms to use right at the peak of the mass exodus from on-prem Exchange

What are the alternatives to M365? Seems like a monopoly to me (Bad Microsoft from the 90’s)...time for another antitrust suit? This kind of pricing strategy strikes me as supremely arrogant. Or, another way to steer users away from partner solutions like ours. Ugh. 💀

The main traditional alternative to M365 without getting chased out off the meeting room suggesting some small open source software, has always been the on-premises versions of Microsoft’s products, such as Exchange Server 2019. But when Exchange Server vNext is released, you have to have it as a subscription anyway, no more perpetual CAL licensing is allowed. Microsoft are certainly moving faster with Teams as there isn’t an on-premises version of it, unless you count its previous life, Skype for Business, as much as I enjoyed SfB, it’s certainly VERY different to Teams still...

Userlevel 7
Badge +17

The hosted rental offerings are nice until the provider tries to press more and more money out of the customers for the same delivered value. And Microsoft seems to go in this direction the last times...

Badge

We’ll be using Model B pricing. Model A has specific requirements - and requires the user to have a specific license which won’t be an option for all our users.

If you think an average user sends 22-30 messages per day, and a power user maybe double or triple that you can start to figure out what the cost model might be. In v6a initial support will be for public channel only, which is usually only 10% or so of total message traffic. But you should validate this with how you expect Teams to be used in your deployment.

In the future if all messages were to be backed up instead of public channel only, there is a problem as there isn’t a good way to uniquely organize this, as right now those messages are looked up per user.

GET https://graph.microsoft.com/v1.0/users/{id}/chats/getAllMessages

With this example API call, messages sent from this user and to this user show up, resulting in data duplication. Hopefully there will be a better way to go about this going forward while still being able to read an entire conversation stream. For now, with public channel backup we do not have this issue.

Userlevel 7
Badge +13

Thanks for your insights @johan.h! From my feeling the costs shouldn't explode but still there's some uncertainty; especially for the future when more and more will be done via the Graph API. Does the API work incremental or will every run touch every message?

Badge

Yes, there is a way to only get posts between specific points in time. The official SLAs for how long it takes for this API layer to represent current state in Teams still need to be published by Microsoft.

From a cost perspective it is really hard to say as it is not easy to predict how individual organizations will use this feature. Having a per-message cost is certainly a challenge and this can be quite significant if you look at Teams backup in general, not just public channel backup. It hopefully is still better than having to have a specific user license in order to use this API though.

Comment