These are my findings around Modern Sites without Office 365 Groups. It is, of course, a subject to change.
Today (2020-02-21) when you create a Modern Team Site without a group, you will get a site with the template STS#3. This oldie has been around for a while, hasn’t it?
I would always recommend creating Office 365 Group Connected sites.
How it is created
Through PowerShell/REST or from SharePoint Home, if your account is not allowed to create Office 365 Groups, it will automatically create a site without a group.
Site Creation Speed
It is really fast, much faster than the old STS#3, so something is different.
Custom Script
CustomScript is enabled. Which is the same as DenyAddAndCustomizePages=Disabled. CustomScript is a security risk, so I hope Microsoft will change that.
Groupifying
Yes, connecting to a new group is possible.
Listing Team Sites without Office 365 Groups
In SharePoint Admin you can filter them based on “Team Site (no Office 365 group)”
Want to translate your MS Forms into other languages? Create a form, not a quiz. It is available in both Forms and Forms Pro licenses.
Today I want to share one of my findings. One of those that seem obvious once you know, but that take time to find out.
Unfortunately, there is no official comparison of what is included in MS Forms vs. MS Forms Pro. So I thought that the ability to have forms in multiple languages was connected to the license.
It showed after many tests, that it is up to the type of form. The Form has the “Multilingual” feature. The Quiz does not have. Why? I don’t know. 🙂
Lesson learned: If you want to have your form in different languages, create a form, not a quiz in MS Forms.
One of the reasons why it is confusing is also the translation into Swedish.
Form – Formulär
Quiz – Frågeformulär. You can say “Quiz” in Swedish, too. Frågeformulär is very confusing.
English interface of MS FormsMulilingual only availalbe in a form, not a quiz
Sometimes all you need is just a simple static web page: instructions, a landing page, a collection of links. I think I have a perfect use case for Sway. Consider a scenario similar to what Laura Kokkarinen writes in her blog post:
An external user invitation needs an inviteRedirectUrl. Usually it is myapps.microsoft.com. In Laura’s case it was a given extranet url.
In our case we don’t know where an external user will land. After the invitation the external user will be added to some team or a collaboration site.
The default myapps.microsoft.com is a tool where a user can administer his account and accesses, but it might be a confusing place to be sent to after the invitation acceptance process.
A simple static page with clear information is just enough in our case. Fortunately, there is Sway, a simple (but still great) web page builder.
An example of a landing page, defined in Sway.
Following alternatives were considered for our landing page:
An “extranet” page in SharePoint Online. It takes time to set up if you don’t have an extranet.
A page in a public portal. Comms and IT must be involved.
A static web page in a blob storage / Azure CDN. It requires some basic web development for design and IT-driven deployment.
Azure App or Azure Function. Actually here it would mean going beyond static. For the initial phase, serving a static page, would also mean basic development and deployment by IT.
Advantages of a Sway page
Easy to create a static web page
Beautiful templates and an easy way to alter the design
Can be driven by the business/comms completely. We only need the url (to put into the invitation call to MS Graph).
Does not require any development or deployment.
Videos, documents can be embedded easily
A sway can be shared with anyone using the link. It means no additional infrastructure steps for this to work (such as firewall, dns etc).
There are some disadvantages, too:
The domain is too generic: sway.office.com. It might look suspicious to some users. Maybe there is a way to use own domain?
A Sway cannot have different languages and switch them based on the user’s locale. It would be great to have something similar to the “Multilingual” functionality in Forms. But still, as a static web page, Sway is doing great, even without the “Multilinguality”.
Summary
Sway is an easy “business friendly”, no-code solution for simple, still good-looking web pages, that can be created and updated in no time and shared easily. Being a member of the bigger Microsoft 365 ecosystem, it fills a certain gap where the business can work together with IT and deliver solutions faster.
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.
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 like 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.
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.
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:
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.
Recent Comments