Sunday, May 31, 2020

How-To include an external as presenter in Yammer Live Event

After I earlier this week did the pleasant discovery that and how-to an external can be involved as presenter in a Teams Live Event, I decided to test whether same is possible within Yammer Live Event production. That could work, as Yammer Live Event production can be via Teams. The short report out: Yes, also this proofs possible!
The enabling preconditions (external known as Azure AD B2B guest in organizing Teams, and switched in Teams App to the organizing tenant) and steps are comparable with involving an external in Teams Live Event presentation, although few significant differences:
  1. In the organizing tenant, schedule in producer / organizer role within Yammer a new Live Event. Crucial also here is to select that the production will be done 'via Teams', not 'via External app or device'. In this step in Yammer UI, do not try to invite the external as presenter as that fails: Yammer does not allow the external to be resolved (unless you have enabled external access of the Yammer channel itself)
  2. In Yammer of the organizing tenant, navigate to the scheduled Live Event and click on "Produce (Open in Teams)". After the Yammer Live Event is opened in Teams App, click 'Join now'.
  3. Crucial step: in the internal Teams meeting of the Live Event, click on the button 'Show participants'. And in the Teams meeting context, invite the external person via his/her external guest identity;
  4. Under the preconditions that the external person is active in Teams, and switched there to the organizing tenant, (s)he receives a request notification to join in the internal Teams meeting of the Yammer Live Event
  5. The invited external accepts the invite to join this active Teams Meeting, and can then share content + video in the meeting context of the Yammer Live Event;
  6. The Yammer Live Event producer waits in the Teams Live Event production room until the external person has joined, and shares content in the internal meeting of the Live Event. When visible, the producer is in control to select content and/or video of this external presenter in the queue;
  7. The producer pushes from the queue to live, and starts the Live Event;
  8. The audience of the Yammer Live Event see the content and/or video of the external presenter;
  9. And audience on-the-go can watch the external presenter in the Yammer Mobile App;

Saturday, May 30, 2020

How-To include an external as presenter in Teams Live Event

When it comes to organizing a webcast, Microsoft 365 offers multiple options: Teams Meeting, Stream Live Event, Teams Live Event, Yammer Live Event. Each with their own differentiating characteristics, and you can select which best fits the specifics of your planned event. A significant differentiator of Teams Live Event is that you can extend beyond internal audience only. Either full public open, or still restricted audience by inviting externals as authorized via Azure AD B2B in your tenant. In the B2B guest model, the external access into the Live Event can then be secured by multi-factor authentication (MFA), to protect the company information shared for external access only in trusted context.
A pleasant discovery I did this week is that the authorized external involvement also extends to the Presenter role: you can include in the set of event presenters also identified people from outside your own organization.
The enabling conditions:
  1. The Live Event must be produced via Teams itself, not produced by External app or device. Reason is that the latter delegates to MS Stream for processing and delivery, and that Microsoft 365 service up today sadly still does not support external access;
  2. The external person must be known in your tenant, either as Azure AD B2B guest or via Teams Federation;
  3. The Live Event organizer / producer must invite the external person via his/her external guest identity in the Presenter role;
  4. The external person must be authorized as member to a Teams instance in your tenant
  5. And as first crucial: to be allowed in the Live Event as presenter, the external person must at the presentation time switch in Teams to your tenant. Without this step, the external person sees in own Teams calendar the Live Event as meeting; but when trying to join that from own tenant will be blocked with notification
    "This event is in <external-tenant>. To join, you'll need to be in that org,too."
    If the organizing tenant has enabled MFA as conditional access rule, the external person will be challenged for that before secure and governed allowed access in the organizing tenant.
  6. And second crucial: to actively join the live event the external person cannot go from Teams calendar once switched to the organizing tenant as it is not administrated there for the external person. Workaround is to join the 'external live event' via the invitation mail that the external person received in the own mail inbox when the Live Event organizer identified the external as an event presenter. Click on 'Join Live Event' seamless opens the Teams App of the external person in the internal producer/presenter meeting of the Teams Live Event within the organizing tenant. As result of the tenant-switch (previous step), the external person is now namely already authenticated and known in the organizing tenant.
After following the above steps, the external person is from perspective of the Teams Live Event organization just another presenter, who is authorized and enabled to share video and content in the event. And can communicate with the producer + other presenters in the chat of the internal Teams meeting to align on the event production.
From the perspective of the organizing producer, (s)he remains in control to determine which content of the presenters included in the Teams Live Event production to actual put live for the audience. The final control remains thus within the organization hosting the live event to its invited audience - internals, potential authorized guests, or full public-open.

Sunday, May 24, 2020

MS Teams Channels - Yet Another Inconsistency on SharePoint Permission handling

Microsoft introduced Office 365 Groups as overarching concept to bring consistency in Office 365 permission management. Each single Office 365 Group manages authorization to a multitude of diverse Office 365 services (MS Teams, SharePoint Online, Planner, Exchange Online), in theory simplifying on the model in which each tool individual applies its own permission management.
In practice, Microsoft itself struggles with the consistent application of this new permission management model. In previous post I visualized the differences in permission management of Communications Site versus Modern Teams Site. Yet another difference is visible on the level of SharePoint site collection that is associated with a MS Teams channel. In the associated site of the main channel, Microsoft utilizes the concept of Office 365 Groups as overarching permission management. However, in the associated site of any private channel, the notion of Office 365 Group is missing.
Comparision Permission Handling + Management within associated site of Main vs Private Teams channel
Observations:
  1. In the associated site of the Teams main channel, site authorization is delegated done via Office 365 Group.
    1. The SharePoint Members permission Group has as single member the Office 365 Group ‘Members’
    2. The SharePoint Members permission Group has as permission level 'Edit'
    3. The SharePoint Owners and Visitors permission Groups are both EMPTY
    4. Instead, the ‘Owners’ responsibility is assigned by having the full O365 Group 'Owners' as SCA
  2. In the associated site of a private channel, site authorization is still on named accounts level
    1. The SharePoint Members permission Group has as members the named accounts of everyone authorized in membership in the private channel, both the owners and members of the channel
    2. The SharePoint Members permission Group has as permission level 'Contribute'
    3. The SharePoint Owners permission Group has as members the named accounts of the persons that are owners of the Teams private channel
    4. And these same named persons that are owner of the Teams private channel, are assigned SCA
I think this deviation is driven both by the current situation that Office 365 Groups itself does not support hierachy and subsets, plus the restricted usage scope of a private channel. A private channel is meant to restrict access to certain content in the Teams instance, but it is not meant itself as a container hub consisting of multiple tools. As example, you cannot associate a Planner Plan with a private channel. There is thus in the context of private channels less need for the overarching permission management concept via Office 365 Groups.
A concern with this effectively broken permission management in private channel compared to Teams instance itself, is what happens when on the Teams instance level a membership is revoked. Turns out that on Teams level itself the effect of this cascades to any of its potential private channels: whenever an account is removed as member in Teams instance, the same account is also automatic revoked as authorized member in any of the private Teams channels.