Let’s say you’ve decided to make some custom functionality available to your users as a SharePoint 2013 app. You’ve decided that this will be published to the appropriate internal SharePoint App Catalog (as opposed to being available in the public SharePoint Store). In a large company, it’s probably not realistic to expect all users to install such internal apps, even if we want to make the functionality available to everyone.
The answer *might* be to use one of the options for deploying the app at “tenant scope”. This works for both on-premises deployments and Office 365/SharePoint Online. This article looks at these options, but just as a reminder of where we are in the overall series, here's the table of contents:
- SharePoint 2013 apps – architecture, capability and UX considerations
- Getting started – creating lists, content types, fields etc. within a SharePoint app (provisioning)
- Working with data in the app web, and why you should
- Access end-user data (in the host web) from a SharePoint 2013 app
- Rolling out SharePoint 2013 apps to the enterprise - tenant scope and PowerShell installs [this article]
- Azure is the new SharePoint ‘_layouts’ directory
- “Host web apps” – provisioning files (e.g. master pages) to the host web
- “Host web apps” – provisioning fields and content types
- Working with web parts within a SharePoint app
- Using app parts (ClientWebPart) to bring app elements into the host web
- Using permission and capability requests
- Deployment to named site collections
- Deployment to all sites under a particular managed path
- Deployment to all sites created from a certain site template
I said *might*. When deploying apps in this way, there is a crucial detail to be aware of – something which could either be highly-desirable or a deal-breaker. Essentially, all installed instances of the app *share* a single app web. This means any lists or libraries you provision as part of your app, are shared amongst all the webs where the app is installed. As I say, this could be exactly how you want your app to operate, or completely against it’s design.
The process for using this model is as follows:
- Upload app to App Catalog.
- Install the app to the App Catalog site collection – yes, for this scenario we actually have to install the app there (for reasons which will become clear later).
- Go to the Site Contents page and find the app. On the callout menu here (and only here), you’ll have an action labelled ‘DEPLOYMENT’:
- Click the ‘DEPLOYMENT’ button to go to the admin page.
On this page, I see the 3 options for deployment – individual site collections:
..or deploying to all sites under a Managed Path, or all sites created from a certain template:
Once you’ve selected appropriate options and hit OK, after a few minutes time you’ll find your app has landed in the target locations:
Important aspects of tenant-scoped app installations
As I highlighted before, all app instances share a single app web. The way this works is that the instance which is installed to the App Catalog site is used for all instances – effectively the user is always redirected to this URL on the app domain, regardless of which site they entered the app from:
There are also important by-products of this:
- Users in sites where the app is installed cannot remove the app – regardless of their permissions there
- This makes sense because they would effectively be uninstalling the single instance used by everyone
- Individual “usages” of the app do not get reported by Get-SPAppInstance – only the instance in the App Catalog site gets returned (N.B. applicable to on-premises SP2013 only)
Any changes to the app (e.g. app upgrades, app removal) need to be managed at the instance which is installed to the App Catalog site.
But I want something else - to roll out my app in bulk, but it NOT to be “single instance”
Then in this case, PowerShell is your friend – this is a two step process to install a new app:
- Use Import-SPAppPackage to initially install the app to the site collection, then..
- Use Install-SPApp to install to individual webs
For a full list of cmdlets around SharePoint 2013 apps, see App Management Service cmdlets in SharePoint 2013 on TechNet. Corey Roth also has a post on some of these cmdlets.
If you’re on Office 365 (with it’s limited set of PowerShell cmdlets, as of April 2013), you’ll need to accomplish the same thing using one of the client APIs. I’m starting to form the view that .NET CSOM code “wrapped” with PowerShell is a good way to do this – since it can then be integrated with TFS automated builds etc.
Happy app installing!