Worth leading with directly, since it changes what this post can actually be about: the classic SharePoint Add-in model — what this post originally covered — is fully retired. Microsoft deprecated it in November 2023 and it stopped functioning in any tenant as of April 2, 2026, with no extension. Any script built around installing a SharePoint Add-in no longer does anything useful; the app either won’t install or won’t run. This post now covers what actually replaced it, and the real PowerShell cmdlet for installing apps today.
In this post: The retirement, in brief · The related ACS retirement · If you still have add-ins deployed · Install-PnPApp: the real current cmdlet · Installing to multiple sites, correctly · Verifying the installation · Related reading
The retirement, in brief
The SharePoint Add-in model — SharePoint-hosted and provider-hosted apps, installed via an App ID against the App Catalog — was phased out over more than two years, not pulled overnight: new tenants stopped getting it as of November 2024, the public marketplace stopped accepting new listings back in March 2024 and stopped allowing acquisitions entirely by July 2024, and the model itself stopped functioning tenant-wide on April 2, 2026. If a site still shows an add-in in Site Contents, it’s a leftover reference, not a working piece of functionality — clicking into it won’t do what it used to. Microsoft’s recommended, and now only real, path forward is the SharePoint Framework (SPFx), which uses a genuinely different deployment and installation model.
The related ACS retirement
Worth understanding as the actual mechanical reason provider-hosted add-ins stopped working, not just “the model was retired”: provider-hosted add-ins authenticated back into SharePoint using Azure ACS (Access Control Service), and ACS itself was retired on the exact same date, April 2, 2026, after already being unavailable to new tenants since November 2024. The two retirements are linked, not coincidental — even if a provider-hosted add-in’s external service is still running fine, it lost the specific mechanism it used to call back into SharePoint APIs. Microsoft’s guidance for anything still depending on ACS-based auth is to move to Microsoft Entra ID for authentication and authorization instead — a genuinely different auth model, not a renamed version of the same thing, which is part of why this isn’t a quick config change for anything still relying on it.
If you still have add-ins deployed
Worth checking rather than assuming: a broken add-in reference doesn’t remove itself, and it’s worth explicitly finding and cleaning up rather than leaving a non-functional entry in Site Contents that confuses the next person who finds it. Microsoft’s own modernization guidance covers assessing what a given add-in actually did and mapping it to an SPFx equivalent — a provider-hosted add-in calling out to an external service maps most directly to an SPFx web part or extension calling the same service through modern authentication, not a like-for-like drop-in replacement. There’s no automatic migration path; each add-in genuinely needs to be rebuilt as an SPFx solution if the functionality is still needed. Finding what’s actually still referenced across a tenant is worth doing with a script rather than clicking through Site Contents on every site by hand — `Get-PnPApp` against each site returns what’s installed, and cross-referencing the results against the classic add-in app catalog (rather than the modern app catalog SPFx solutions live in) is the fastest way to build an accurate list of what genuinely needs replacing.
There is no `Install-PnPTenantApp` cmdlet — the real, current one is `Install-PnPApp`, which installs to whatever site your PnP connection is already pointed at, not to a site URL passed as a parameter.
Install-PnPApp: the real current cmdlet
Worth a direct correction, since it’s the kind of thing that looks plausible and fails silently: there’s no cmdlet named `Install-PnPTenantApp` in current PnP PowerShell. The real cmdlet — for installing an SPFx solution package from the app catalog to a site, which is the actual current equivalent of what add-in installation used to do — is `Install-PnPApp`. It has no `-Site` parameter; it installs to whatever site your PnP connection is currently pointed at, controlled by `Connect-PnPOnline`, not by an argument passed to the install command itself.
# Connect to the specific site first -- this determines where the app installs
Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" -Interactive
# Install from the tenant-scoped app catalog (default) to the connected site
Install-PnPApp -Identity "99a00f6e-fb81-4dc7-8eac-e09c6f9132fe"
# Or from a site-scoped app catalog instead
Install-PnPApp -Identity "99a00f6e-fb81-4dc7-8eac-e09c6f9132fe" -Scope SiteThe Identity is the app’s ID as it appears in the app catalog, retrievable via `Get-PnPApp` if it isn’t already known — `Get-PnPApp -Identity
Installing to multiple sites, correctly
Because installation depends entirely on the current connection, a bulk-install loop needs to reconnect for every site, not just call the install cmdlet in a loop against a list of URLs — a script that skips the reconnect step will silently reinstall to whatever site the last connection pointed at, repeatedly, rather than actually rolling out across the list:
$AppId = "99a00f6e-fb81-4dc7-8eac-e09c6f9132fe"
$SiteUrls = @(
"https://yourtenant.sharepoint.com/sites/site1",
"https://yourtenant.sharepoint.com/sites/site2",
"https://yourtenant.sharepoint.com/sites/site3"
)
foreach ($SiteUrl in $SiteUrls) {
Connect-PnPOnline -Url $SiteUrl -Interactive
Install-PnPApp -Identity $AppId
Write-Host "Installed to $SiteUrl"
}For a genuinely large rollout, `-Interactive` prompting per site defeats the purpose of automating it — certificate-based app-only authentication is the realistic way to run this unattended across dozens of sites without a sign-in prompt for each one.
Verifying the installation
Checking Site Contents in the browser works for a one-off install, but doesn’t scale to verifying a bulk rollout across many sites. `Get-PnPApp -Identity
Related reading
- Start your SharePoint with SPFx — building the replacement for what add-ins used to provide.
If a search brought you here looking for add-in installation steps, the accurate answer as of this year is that the model itself is gone — worth redirecting the effort toward an SPFx solution rather than debugging why an add-in install script that used to work no longer does anything.
App Catalog Authentication Automation Backup Compliance Content Type CSS Flows Google Javascript Limitations List Metadata MFA Microsoft Node NodeJs O365 OneDrive Permissions PnP PnPJS Policy PowerApps Power Automate PowerAutomate PowerPlatform PowerShell React ReactJs Rest API Rest Endpoint Security Send an HTTP Request to SharePoint SharePoint SharePoint List SharePoint Modern SharePoint Online SPFX SPO Sync Tags Teams Termstore Versioning