Change internal group names

[StefanKi]

Hi,

today we had problems with the provisioning. To fix that I saw that Microsoft has change by some groups form “c:0-.f|rolemanager” to “c:0t.c|tenant”. Can anybody please explain why the do the change? And where I can read about it?

Thanks

Stefan

[#2]

I have the same problem can anyone answer this question?

Thanks!

[#3]

Same here... Does anyone have an idea what happened??

[#4]

Just happened on our tenant also. What a farce, I use these groups in various scenarios, nothing from Microsoft as usual!

[#5]

Same happened on our tenant without any announcement.

[#6]

Same here. We have duplicate "Company Administrators" now with the “c:0-.f|rolemanager” one being outdated . This is messing up scripts for us. What does this change mean?

[#7]

I am now seeing this as well and it is affecting our provisioning. 

[#8]

Same happend in our tenant. Seems over the weekend something has changed without any heads up, which now is causing our sites to be provisioned (using PnP Provisioning templates) without the correct permissions.

[#9]

It is very interesting respond. The change of the internal group names comes over a time period in different tenants. What says MS to it?

@VesaJuvonen can you please somting to it?

[#10 · Accepted solution]

I'm not really aware of this issue or the change behind of it. Please open an official SharePoint Online support case for asking details, so that the request would fall on the official process.

[#11]

Just made a support ticket and got the following response:

"This is by design. This tenant is using the objectID as the claim encoded loginName in userinfo. This is something that all tenants will be transitioned to in the future. We will start using objectID instead of SID values for groups within SPO. "

[#12]

Typical Microsoft response, I think we all realise that this is "by design" the point is that they roll it out without telling anyone!

[#13]

This is breaking provisioning code for me as well. It doesn't seem that EnsureUser works with the new ID, whereas it worked with the old one. Has anybody been able to use EnsureUser against one of the new IDs?

[#14]

For what it's worth Web.EnsureUser no longer works using App-Only permission but still works using the new IDs and user authenticated ClientContext. So I'm back in business.