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...

Beware: User Information List (UIL) acts as memory for PeoplePicker when need to renew Azure AD B2B guest account for changed email

In Azure AD B2B, guest accounts are provisioned and redeemed with as their unique external account identifier, the own external email address of the invited guests. In rare situation that the external email changes, the guest account situation needs to be synchronized with this external identity change. However, as the email address is the primary identifier, it is not possible to change this as attribute in the existing Azure AD guest account. One needs to create in the Azure AD of the inviting company a new guest account based on the new / modified external email address, and potentially can also delete the no longer valid old guest account. On the SharePoint Online side, in each site collection in which the guest needs access, the access must also be repeated for the new guest account. Something to be aware of in such situation is the relationship between SharePoint PeoplePicker and the hidden User Information List (UIL) in site collection. The PeoplePicker uses UIL as one of its entrances to try to resolve user information for looked-up user name. As of SharePoint 2013, whenever an account on individual basis is granted access to a SharePoint site collection, immediate an entry for that account is administrated in the UIL (in SharePoint 2010 and before, the addition in UIL was delayed until first access by the authorized account). The effect in the use case where guest account is renewed by deleting from and creating new, is that the PeoplePicker default will still resolve to the user entry in UIL that was created there when earlier the guest was authorized on the previous guest account. Resulting in an inconsistent situation: the guest is assigned a new Azure AD guest account, the former might even be deleted in Azure AD, but in SharePoint Online via UIL as memory the previous account is selected by PeoplePicker upon granting access. Effect is that the guest can successful logon with the renewed guest account against the Azure AD of inviting company, but in the next step this authenticated guest account is not granted access in the SharePoint Online site: "You need permission to access this site". The way to resolve this is to go as Site Collection Administrator (SCA) into the UIL through <site-url>/_layouts/15/people.aspx?MembershipGroupId=0 , select the entry that refers to the previous guest account, and in the 'Actions' menu select "Delete users from Site Collection". After this corrective management action, the PeoplePicker on looking up the guest (by name or email) will no longer find the stale entry in the UIL, and create a new one that corresponds correct with the renewed guest account. And the invited Azure AD guest is enabled to successful access the site via modified email address as his/her 'bring-your-own-identity'.

Peculiarity with Azure AD B2B and Modern / Active Authentication for guest accounts

In the authentication model of Azure AD B2B, external guests are granted access on concept of 'bring-your-own-identity'. The general applied pattern in AAD B2B usage is to invite guests on their email address as the own identity. For invited guests from an organization that itself utilizes Azure AD for their cloud identity management, in AAD B2B the authentication flow delegates to the external Azure AD (see). This can result in a peculiarity, in which the invited guests after successful first authentication that is federated against the own external Azure AD, in the 2nd step cannot successful pass the MFA challenge via the Microsoft Authenticator App against the Azure AD of the inviting company. The situation arises where in the external Azure AD (of the invited organization) the UserPrincipalName (UPN) differs from the primary Office 365 email address, and the external access is via a client application that utilizes modern / active authentication. In such situation, the inviting company should invite the guest on basis of their Azure AD UPN, and not via their different Office 365 email / SMTP address. For client applications that apply passive authentication (aka: webapplications) it works fine to explicit logon with the own email as their Office 365 identity. But clients that utilize active authentication get into a conflict situation: the automated logon in active authentication flow against the external Azure AD is done on basis of the UPN, afterwards the authenticated account in the client application runtime context is equal to the UPN value of the logged-on guest. However, as the MFA enrollment is earlier done on basis of the email as guest identity, the result is an endless loop in the Authenticator App failing due mismatch in authenticated UPN logon and MFA-enrolled email.

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)