Redeploy your SPFx Extension to SharePoint

One of the charms of SPFx Extensions is that they apply tenant-wide: they can be configured for immediate utilization in all modern site collections in your tenant. On SharePoint foundational level this works via the concept of good-old CustomAction that is injected into the context of each modern site collection. In the SPFx Extension package the CustomAction is configured as Feature deployment. Via the parameter 'skipFeatureDeployment' in the package-solution.json (see 'Tenant-scoped solution deployment for SharePoint Framework solutions') you can configure the SPFx Extension to be immediate available across all the sites in the tenant when the solution package is installed to the tenant app catalog, without need to explicit activate the CustomAction feature in each individual site.

This works out fine on the initial deployment of your SPFx extension: the deployed SPFx header automatically is included and active on each site.

On initial deploy, SPFx Extension included once in each modern site

However, in case of need for redeployment, you must be aware of a current glitch: the SPFx Extension gets multiplied per each re-deployment. The cause of this is in how the (semi)immediate and tenant-wide application of the CustomAction is applied. The CustomAction is not injected in the scope of each individual site (Web.UserCustomActions does not include the CustomAction of the SPFx Extension); but is injected as Tenant Wide Extensions. In case of "skipFeatureDeployment": true in the package-solution.json file, on upload / install of the .sppkg file in the tenant App Catalog the administrator is asked to set the 'Make this solution available to all sites in the organization' checkbox. If set, a row is added in the list 'Tenant Wide Extensions' in the App Catalog site. And on re-upload / redeploy, the checked setting is applied again, resulting in duplicate entries for the same SPFx Extension in the Tenant Wide Extensions list. This results that the CustomAction is applied multiple times per each site, and therefore that the SPFx Extension is included multiple times in each site...

As side-effect of re-deploy, SPFx Extension is multiplied in 'Tenant Wide Extensions' list

Result is that the SPFx Extension is included multiple times per each site

Correcting this faulty situation is simple once you know how-to (thanks to Vesa Vujonen for fast response on support question raised): just remove the duplicate entries from the Tenant Wide Extensions list. Mind you, it can take some elapse time before the effect of this is structural applied accross all the WFE's involved in serving the sites of one's tenant.

Fix by removing the duplicate rows in Tenant Wide Extensions

Then the SPFx Extension again included once, and referring to latest package version

How-to remain in control of Live Events scheduling

See previous post, in the production of a Stream Live Events are 3 different roles involved:

• Organizer
• Producer
• Presenter

The organizer is the person that can schedule / create new Live Events, and becomes the owner of them. Although there is no limitation stated on the amount of Live Events running in parallel, it makes perfect sense to govern this. You don't want to risk that the webcast experience of the CEO Townhall is hampered because too many other Live Events are running within same or overlapping timeslot. In order to avoid wildspread of Live Events, Stream supports via admin settings that the authorization to create Live Events is restricted to specific identified persons only / not for everyone in your organization.

The person creating / scheduling a Live Event, automatically also becomes the owner. However, in the differentiation of the webcast roles; the organizer should not need to be involved in any of the production aspects on the actual moment of the event. To achieve that, the person that will act as the producer of a specific event, must also be made the owner of the scheduled Live Event. As owner, the producer can pick up the scheduled Live Event, set it in edit mode, and then start and stop the event from the Stream webapplication.

Organizer creates / schedules (on request of Producer) a new Live Event

Organizer assigns / shares ownership of the scheduled Live Event to the Producer

On scheduled datetime of webcast, the Producer looks up the scheduled Live Event in Stream web application

On scheduled date of webcast, the Producer starts Setup of the Live Event

On scheduled date of webcast, the Producer is in-control to start the actual broadcasting once the production encoder sends the stream input signal

Plug-In outside producer in Stream Live Events

In a broadcast execution via Stream Live Events, the following roles are involved:

• Organizer
• Producer
• Presenter

(source: Get started with Microsoft Teams Live Events). The person within the Organizer role schedules the live event, and requires the proper authorization in your tenant for that. But next the system design of Stream Live Events allows that for the production part you can delegate to outside your company infra. The plug-in interface for this is the unique RTMP(S) ingress endpoint address of the scheduled Live Event. This endpoint is accessible on the public internet. The producer can configure the encoder on the production / event location to stream as input of the Live Event for broadcasting within your Office 365 tenant. The ultimate production control remains with the authorized owner(s) of the Stream Live Event: to start the actual broadcasting once the received stream input is ok for sending to the audience, and stop the Live Event once the event / presenter is finished (and also when in unlikely case that the producer produces a live recording that is inappropriate or non-compliant with your business policy).