Be aware: ''Check Permissions" does not report M365 Group authorizations until first access

The new and default permission model for Modern Team Sites is via the 'owning' Office 365 Group. I discovered a functional flaw in that: on accounts authorized for site access via the Office 365 group, the SharePoint 'Check Permissions' capability reports "None" until first site visit of an authorized account (which on SharePoint level results that the account is administrated in the (hidden) site users list). I reported this to Microsoft Support, and they reproduced + confirmed the behavior in an arbitrair tenant. Their first response was "this is expected behavior", but I strongly disagree. We use and rely on 'Check Permission' to assess whether a person has access or not to a SharePoint site. And the reliability of this access-check should not be dependent that the assessed person has actually already once visited the site.

Update: in call with Microsoft Support they motivated the "this is expected behavior": it is expected from how it is technically build within SharePoint.... When I re-stated that on functional view this is not expected behavior, they agreed and asked me to submit as UserVoice suggestion; so that the development team can triage it for product fix.

Inconvenient authorization management in 'classic' MS Stream

In the corporate usage of Microsoft Stream as Enterprise Video Portal (EVP), authorization to watch videos is also applied on 'need-to-known' base. In current Stream, it turns out a bit inconvenient to execute effective permission management.

First issue is that it is made complex to nearly impossible to efficient configure permission management on a collection of videos. The root cause of this is in how Microsoft Stream handles the authorization and organization of the video store: "In Microsoft Stream, you can use channels and groups to organize and grant permission to your videos" [Source: https://docs.microsoft.com/en-us/stream/groups-channels-overview]. This is actually not a valid statement. Indeed Stream (aka Azure AD) groups "are both a way to organize videos and to control access to videos", but channels merely "are an organization method for videos, but not a permission method". Limiting for efficient permission management is that Stream portal does not include a capability to logical associate video(s) within either a Group or Channel, this is only supported initial on the moment of adding / uploading video(s) into Microsoft Stream. Once already stored in Microsoft Stream, the only possible way to associate video(s) with additional groups or channels it to do this per video, via the manual Add to group/channel action in the video-edit menu. When this must be done for larger collection of videos, this is a cumbersome and time-consuming effort.

Second issue is that Stream suffers from a delay before the indirect authorization assignment via Stream groups is actual applied (becomes active). In situation that authorization to watch a certain video is managed by one or more Stream groups, authorizing another person for access by adding her/his Office 365 account to an authorized group (e.g. via Azure Portal), does not immediate grant the person allowed access to the video. In reality it can take up to even an hour before the group based authorization within Stream context is updated to incorporate the new added account. Until then, the person remains confronted with Stream access denial on the video.

Even worse, similar effect occurs when revoking the access by removing from Stream group. This is neither immediate effectuated. Luckily the elapse time period is in this situation shorter, max 1 to 2 minutes; not a full hour. Still, immediate access revocation on unjustified granted video is not possible.

Perhaps within new Stream, in which the video storage moves to SharePoint Online, the authorization management improves. Not 100% confident yet, as Modern SharePoint also uses Azure AD groups for permission management. However, experiences within regular SharePoint Online usage are that any change in the Azure AD group(s) are almost immediate applied for access control, both on access assignment as revocation.

Beware: the omnipresent of Office 365 Groups complicates Information Architecture

Pre Office 365, setting up your information architecture was so much simpler (to understand)...

So your organization has implemented Office 365 as office productivity suite, which provides to you the richness in its various services / tools to employ. Say as a business department I need:

• A place to store documents ➔ create in SharePoint Online a Modern Site
• A place to work and chat together ➔ create a MS Teams instance
• A place to plan work ➔ create a plan in MS Planner
• A place to store and expose department videos ➔ create in MS Stream a Stream Group
• A shared mailbox ➔ create via Outlook an Office 365 Group

However, one of the result of these 5 create actions in different Office 365 Services is that you do not have one (1) SharePoint site to your exposure, but actually five (5)!

And all of these 5 Modern Sites are created alike: same structure in the site, layout; all a standard provisioned Modern Site

And also in Azure AD the same multiplication effect is visible, noticable as an Azure AD Group (actually: Office 365 Groups):

Lesson: you need to think upfront on your Information Architecture, and then setup your utilization of the Office 365 services that it matches. Beware that this governance is hard to achieve, as all the creation in Office 365 is via self-service made so easy...

Execute 'Site information' (logo, privacy settings) on "Modern" team site requires to be Office 365 Group owner

Site information option in Modern team sites is the way to change the site logo and/or the privacy settings. This menu option + application popup dialog is available for accounts that are Site Collection Administrator (SCA). However, this is not enough. As "only" SCA I get the error "Problem uploading your picture. Please try again later." (see also uservoice on this: "Bug? Uploading team logo does not always work"). It appears that one needs to be an owner of the Office 365 Group that is connected to the Modern team site, then one can successfully change e.g. the site logo. Cause of this behavior is that "SharePoint Online team sites that are connected to an Office 365 group use the same logo as the Office 365 group to which they are connected. When you change the logo for your SharePoint group-connected team site, the logo for the corresponding Office 365 group will change also." (Manage your SharePoint site settings)