A non-admin user can create no more than 250 resources in Azure AD. That is one of the many Azure AD service limits and restrictions. A “resource” can be an app registration, an Office 365 Group etc. But I would like to discuss Groups more in detail.
Imagine the following scenario: Your organization has disabled Office 365 Group Creation. Only IT can create new groups. A service account has been set up for creation of team sites. The application permissions are “binary”, either everything or nothing: Group.ReadWrite.All. This service account will hit the limit very soon.
To prove that, I have created a small script that creates 251 groups.
By the way, just for clarification, when create a new group, that will also create a SharePoint site.
Please don’t try this with your real account in production. The 251st request will fail:
The directory object quota limit for the Principal has been exceeded. Please ask your ad ministrator to increase the quota limit or delete objects to reduce the used quota.
Even if you remove, it will take time to get free slots in this limit:
Deleted Azure AD resources that are no longer available to restore count toward this quota at a value of one-quarter for 30 days.
There is not much to do about it. For App Registrations you can create and assign a custom role. But for groups there is no custom roles available.
It might be obvious, but still:
Admins do not have this limit. But not all “admin roles” are really admins. Those roles are excepted:
Those roles are not excepted:
Message Center Reader
I don’t have time to try every admin role, but I suppose only admins that can change global configuration, are excepted, not the reader ones.
Since communication sites do not have an Office 365 Group behind the scenes, a non-admin user will still be able to create such sites even after the limit is hit.
Workarounds and Solutions
Since my scenario for creating groups with a service account does not work, we need to seek workarounds and solutions.
Do not restrict Group Creation
That is the best one. If users can create groups/sites by themselves, then none of this would be a problem. But still, in my scenario, there is a business requirement to control the creation of groups.
Application Permissions Group.ReadWrite.All
That is exactly the opposite of my scenario. This gives that application full access to all groups and files (!). This means, that application can access all Group-Connected SharePoint Sites as well.
Microsoft creates permissions for groups
If we also had “groups” permissions for custom roles, then we could do the same way as with app registrations. Today (2019-10-25), there are only permissions for applications.
Microsoft creates new permission Group.Create.All
If there were a permission for only creating groups, that would solve the problem.
There is a similar role: User.Invite.All, it allows only invitations, not editing All Users.
Microsoft allows exceptions per user
If there were a switch for the 250-limit per user, that would also solve the problem.
Granting the service account admin rights
Granting SharePoint Admin would solve the problem, but at what price? That is safer than Application Permissions Group.ReadWrite.All, since you need to actively add this account to the groups in order to read all the files, but this is still less secure than just a non-admin account.
Having multiple service accounts
If we had account 1..100 and we used every account 250 times. Theoretically it should work, but it is a cumbersome process. You need to keep track of how many groups an account as created, or having the right error handling. How should the password be kept safely. Should the accounts be removed when they have reached the 250 limit?
Group Creation Microservice
To overcome the limits and the ungranularity in the built-in permissions in Office 365, one way to solve it would be a tiny, but a dedicated, and secured service for creation of groups (and sites). It would still need the “hefty” Group.ReadWrite.All Application Permissions, but making it do the only thing and do it right, would mitigate the risks.
It could be a simple Azure Function that few have access to. That could be just a couple of lines of code.
I can’t write in Chuvash in Windows 8 (and all the previous Windows releases). Chuvash is a minority language in Russian Federation. In this blog post I want to summarize the status of the keyboard layout support of the minority languages of Russia and find a way to improve this situation.
In Russia there are 21 republics which have their own official languages alongside Russian and their purpose is to be home for ethnic groups. I’ll focus mostly on the official languages in these republics in this blog post, but it would be interesting to investigate smaller languages as well.
Allmost all of the minority languages of stateless nations use the Cyrillic alphabet (often with additional letters). So it makes it pretty simple to see how many languages are supported in Windows 8. Just Go to the Language preferences -> Add a language and group them by writing system. See the screenshot above. There are only three minority keyboard layouts which are supported:
Bashkir (1,45 millions speakers)
Sakha (Yakut, 360 native speakers)
Tatar (4,3 millions speakers)
The funny thing is that all the three are Turkic languages.
There are two additional language keyboard layouts which are implicitly supported:
These two languages (which are co-official languages in the republic of Mordovia) don’t use any additional letters. That’s it. So they can write using only the standard Russian keyboard layout.
Keyboard layouts in Linux
Just a little comparison. In Linux distributions there are more minority languages from Russian Federation represented. The supported ones can be found in the /usr/share/X11/xkb/symbols/ru file:
Tatar / tt
Ossetian / os
Chuvash / cv
Udmurt / udm
Komi / kom
Sakha (Yakut) / sah
Kalmyk / xal
Bashkir / bak
Mari / chm
All these keyboard layouts were added by the community. I personally sent the Chuvash and Kalmyk fragments of that file to Sergey Udaltsov who created patch files and pushed it to freedesktop.
Windows 8 keyboard layouts and Touch mode
When I tried these three supported minority language keyboard layouts of Russia in touch mode, only one worked! It was the Tatar keyboard layout.
The tatars can type all their additional letters in touch mode as well.
Bashkir and Sakha keyboard layouts use the row above qwerty: 12345… Here is the preview for the classic Sakha keyboard layout:
And what about the virtual touch keyboard layout for Sakha language?
As you can see there are no keys for the additional letters for Sakha language (ҕ ҥ ө һ).
Many minority languages of Russian Federation (the most of them already endangered) miss the native keyboard layout support in Microsoft Windows 8 and Windows 7. Windows is a prevalent operating system in Russia. The support for minority language keyboard layout would help people to use their languages and give more chances for languages to survive. For now there are only 3 languages (besides Russian and implicitly some others like Moksha and Erzya) which are supported in Windows 8 with a physical keyboard: Tatar, Bashkir and Sakha. And only one of them (!) works even in touch mode: Tatar.
The purpose of this post is only to identify the status for Russian Federation minority language keyboard layout support in Windows 8. Microsoft Local Language Program (LLP) seems very promising. I hope we will see more languages of Russia and other countries available in “Add language” menu in Microsoft Windows 8.
Long tap and additional letters in Windows 8 (update 2013-03-16)
There is an interesting counter example in press-and-hold behavior. On a physical keyboard, when you press and hold a character, it repeats. On our touch keyboard when you press and hold, we show alternate characters or symbols. This is something a touch keyboard can do well and a physical keyboard can’t. If you don’t know the specific key combination to show ñ or é or š, for example, it’s painful to type on a physical keyboard. It’s easy to find on the touch keyboard. Practically no one has complained about this departure from convention. We built on it, in fact. You might discover that you can simply swipe from a key in the direction of the secondary key, and that character will be entered, without an explicit selection from the menu. So if you use accented characters a lot, you can get pretty fast with this.
I appreciate this. Here come all the letters I found in the Russian keyboard layout:
Here we have four fully functional language keyboard layouts if you are okay with long-tapping:
ғ ҡ ҙ ҫ ң һ ә ө ү
ҕ ҥ ө һ ү
ң ү ө
ө ү һ
Bashkir and Sakha, I suppose, were considered whilst designing the keyboard layout, and Tuvan and Buryat language letters only happen to be within the Bashkir and Sakha letters range.
Tatar letters aren’t complete in the standard Russian keyboard layout, the reason for that must be, as I mentioned above, the full functional virtual keyboard for Tatar (where is no need for long-tapping).
There is another language which contains all the letters through long-tapping. Kazakh is absolutely a minority language of Russia, but it doesn’t represent a stateless nation.
ғ ә қ ң ө ү ұ і һ
Long-tapping technique could be a solution for many minority languages of Russia: