Why would a tenant-wide extension need to be deployed manually on a target site?

[deanbot]

The first example in the docs for customaction add reference a Tenant-Wide extension in a way that leaves specifics open to interpretation.

Edit: added example code for reference:

spo customaction add -u https://contoso.sharepoint.com/sites/test -t "YourAppCustomizer" -n "YourName" -l "ClientSideExtension.ApplicationCustomizer" -c b41916e7-e69d-467f-b37f-ff8ecf8f99f2 -p '{"testMessage":"Test message"}'

Is this example adding an item to the Tenant Wide Extensions list on an app catalog as identified by t? In my testing this is not the case, rather it adds an action that shows up via spo customaction list

Why would a tenant-wide extension need to be deployed manually on a target site?

How can one activate (edit: or manage) an extension across the tenant with o365 cli? The customaction param contains all the relevant params, is there a way to make it affect the Tenant Wide Extensions list? Does spo listitem add targeting the Tenant Wide Extensions a) create a list item b) activate the extension tenant wide?

[VelinGeorgiev]

Hi @deanbot,

Thanks for your input. You are right the 'tenant-wide' in the customaction command is misleading. I would suggest we update the docs to remove the term from the text to prevent confusion in future. I am sorry if that caused troubles for you!

Currently the CLI does not have a command ready for true tenant wide deployment of application customizer. I am looking at the official documents and they specify that this can be done by ONET.XML inside the solution package, but they do not mention any ALM apis available which is very strange. We will have to investigate and see if we can utilize an API within SharePoint to make that functionality available in the PnP Office 365 CLI.

I will try to investigate in the next weeks if there is an analog in the PowerShell comanndlets and if there is we will be able to replicate that functionality into the CLI as well.

I am also open for suggestions, please do not hesitate to let me know if you are aware of a REST API that we can utilize and we will do it.

Again I apologize if any troubles caused. 🙇‍♂️

[garrytrinder]

You are right the 'tenant-wide' in the customaction command is misleading. I would suggest we update the docs to remove the term from the text to prevent confusion in future.

Given the existing text for the example provided by @deanbot is

Adds tenant-wide SharePoint Framework Application Customizer extension in site https://contoso.sharepoint.com/sites/test

What would you suggest we update this the above text to?

[deanbot]

@VelinGeorgiev no worries! Looking forward to any info you might turn up!

There is skipFeatureDeployment which does something with feature framework (i.e. ignoring feature framework related xml) during spo app deploy - I think it's analogous to checking 'Make this solution available [...]' during manual deploy, but I'm not sure. In addition to whatever it does or doesn't do with feature framework, it will create list item(s) in TenantWideExtensions (if identical list item(s) don't exist) as described by the ClientSideInstance xml.

The question is is there a way to manage Tenant Wide Extension items on the fly. Perhaps it's treated like any other list. If that's the case, a cli method might make that process more standardized/less error-prone. Though it's unclear whether just creating a list item is enough to do all the magic of tenant-wide deployment - i.e. an extension must be deployed, but does it have to be deployed with skipFeatureDeploy for some reason outside of creating a list item in Tenant Wide Extensions?

[VelinGeorgiev]

Thanks for the info @deanbot!

I tried to look for an API in the CSOM from now until august 2019 and Microsoft have not introduced any methods related to this. My personal opinion is that when they built this functionality they must have shipped it with a proper ALM apis so we can manage the active tenant wide extensions properly, but this might not be the case.

Could you point me to that TenantWideExtensions list? Is it in the SharePoint admin site?

If that list is in the admin portal, I assume that everything in that list is more for internal reference since there isn't official documentation. Also, removing item from there might not result to removing the deployed extension from all the sites in the tenant. I will try to play with that list during the next week just to see out of curiosity if there is an event receiver that might trigger uninstall, but even if I find something will be more like a workaround than something that is solid and proven to work.

We can try to play with the ALM apis as well to see if they do not have additional information for active tenant wide extensions.

[deanbot]

It's in the App Catalog site, whatever that might be on your tenant.

[VelinGeorgiev]

Thank you @deanbot ! I will do some research on the topic because I am curious myself and let you know if I can help you with additional info or if you can use additional CLI commands to achieve management of the tenant wide active extensions.

[waldekmastykarz]

If I'm not mistaken, tenant-wide deployment of extensions is twofold:

1. The .sppkg containing the code needs to be globally deployed to all sites (using the skipFeatureDeployment option when using the CLI/REST API/PowerShell)
2. The extension must be registered in the TenantWideExtensions list

When the extension has ClientSideInstance.xml defined for it in .sppkg, it will be registered in the list when the solution is deployed but, if you deploy the same solution multiple times, each deployment will add a new entry to the list leading to your solution loading multiple times! So if I recall correctly, the recommendation for easy deployment was to use ClientSideInstance.xml but for proper control to register the extension in the list yourself either via CLI/PowerShell or manually.

[phillipharding]

I always find this subject a little bit murky, but AFAIK....

The tenant-wide extension list is something of an analog for the ClientInstance feature framework for tenant wide deployment of extensions, which is the normal way of deploying extensions across all sites.

The TenantWideExtensions list is populated from the feature framework files included in solution packages where the solution has been deployed to enable deployment to all site collections either via;

• --skipFeatureDeployment or
• the "Make available to all..." checkbox on the deployment dialog.

--skipFeatureDeployment or "Make available to all..." causes any feature framework files in the solution package to be ignored, which would mean that tenant-wide deployment of extensions wouldn't work - I think TenantWideExtensions is a workaround, around that 😀

In some of my scenarios I want to deploy extensions across all sites, but only activate them on certain sites as part of my PnP/CLI provisioning.
In those cases I'll build the packages without feature framework files and register the extensions by adding appropriate CustomActions to sites using either;

• PnP
• CLI

[garrytrinder]

@deanbot does @phillipharding explanation answer your question?

[phillipharding]

Additionally, by-passing the TenantWideExtensions list and activating Extensions on site collections manually using the PnP/CLI offers the ability to activate Extensions to multiple sites using different extension properties - this is something which AFAIK deployment via the TenantWideExtensions list doesn't offer

[deanbot]

@phillipharding good to know. I tend to use an “allowedSites” & “blockedSites” approach in the properties for tenant wide extensions entries to accomplish separate configuration for separate sites, but this doesn’t scale as well for many configurations.

[phillipharding]

@deanbot as in “allowedSites” & “blockedSites” are your extension props which it uses to determine whether to do something or not?

[deanbot]

Indeed.

[deanbot]

Hi @garrytrinder. See @waldekmastykarz‘s note (emphasis added):

If I recall correctly, the recommendation for easy deployment was to use ClientSideInstance.xml but for proper control to register the extension in the list yourself either via CLI/PowerShell or manually.

So as far as doing this with the CLI goes, can the tenant wide extensions list be modified via the list item cli methods? If so (please test), then either example code should be added to the list item cli documentation, a new cli method should exist for this purpose, or, considering that tenant wide extensions list entries are like centrally administered custom actions, an option should be added to the customaction cli method.
Some use cases for tenant wide extensions list management via cli:

• restore a default configuration for tenant wide extensions on a tenant
• export configuration of tenant wide extensions from a tenant
• remove duplicate activations of a tenant wide extension as created by the “buggy” behavior @waldekmastykarz mentions:

if you deploy the same solution multiple times, each deployment will add a new entry to the list leading to your solution loading multiple times!

• get entires by manifest ID/title/list item ID
• toggle disabled for entry
• nice to have, improve upon the default behavior of the tenant wide extensions list by validating json (consider that a trailing comma in the Client Side Component Properties will keep an extension from triggering without any error message)

Additionally, documentation for customaction should probably say “centrally deployed site extensions” or “site extensions deployed across the tenant” instead of “tenant-wide” to distinguish from the tentant wide extensions list. A tenant-wide extension should mean an extension that is activated across a tenant via the tenant wide extensions list not whether the site extension has been deployed across the tenant.

Those are my thoughts at least!

[waldekmastykarz]

can the tenant wide extensions list be modified via the list item cli methods

Yes, it can, it's just a list

If so (please test), then either example code should be added to the list item cli documentation, a new cli method should exist for this purpose, or, considering that tenant wide extensions list entries are like centrally administered custom actions, an option should be added to the customaction cli method

Yes, we should clarify it, but I don't think that extending the generic command docs is the right place for that. Ideally, I'd say we should rephrase the custom action command description like you mentioned and add sample scripts that show completing the use cases you mentioned.

Appreciate your feedback! ❤️