This was very interesting to read.

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! )

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

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.

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.

@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.

Oh I am sure it will. 

Thank you for this comprehensive share here @regnor 

This is comprehensive @regnor , thank you!

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...

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...

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.

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?

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.