1. 05 | Planning and Configuring Support for Apps
Jason Lee | Chief Technologist at Content Master
Christina Singletary | Senior Content Developer at Microsoft

2. Module Overview Apps for SharePoint Fundamentals
App Permissions Fundamentals
Configuring Infrastructure for Apps
Configuring the App Catalog
Managing Apps for SharePoint

3. Apps for SharePoint Fundamentals
Let’s look at some of the concepts behind service applications in SharePoint 2013.

4. What Are Apps for SharePoint?
Framework for providing custom functionality within SharePoint sites
Cannot run code on SharePoint servers
Can include:
Declarative SharePoint components
HTML/JavaScript
Remote-hosted code
Compatible with SharePoint Online as well as on-premises deployments

5. App Hosting Models: SharePoint-Hosted
JSOM/REST API
SharePoint Site
(Host Web)
HTML
CSS
JavaScript
App Web
There are two different hosting models for SharePoint apps – SharePoint-hosted and provider-hosted. Let’s start with SharePoint-hosted apps.
You provision a SharePoint-hosted app within an [Click 1] individual SharePoint site, just like you’d provision a list or a library. It can be any kind of site – a team site, a project site, a publishing site, etc. In app terminology, this site is known as the host web.
As part of the app provisioning process, SharePoint creates a subsite within the host web exclusively for the app installation, and this is known as [Click 2] the app web. The app web contains all of the contents and resources for the app – this could be declarative SharePoint resources like site columns, content types, and lists, as well as web pages, JavaScript libraries, CSS files, and so on. So you can see that this is nicely self-contained – the app provisions everything it needs to the app web, so it’s not going to affect anything on the host web. It also means that when you uninstall an app, SharePoint can remove it cleanly by deleting the app web – it’s not going to break anything on the host web.
When a SharePoint user interacts with the app in their [Click 3] browser window, they are retrieving [Click 4] HTML, CSS, and JavaScript from the app web. In this model, the only custom code the app can include is JavaScript that [Click 5] runs in the browser window.
The app can use the JavaScript object model or the REST API to [Click 6] interact with SharePoint data on the app web. If the app and the user have sufficient permissions, it can also interact with SharePoint data on [Click 7] the host web.
The key thing to note here is that any custom code is running in the browser window – no code is run on the SharePoint server.
JSOM/REST API

6. App Hosting Models: Provider-Hosted
SharePoint Site
(Host Web)
App Web
.NET Client API
REST API
Remote Web Server
With provider-hosted apps, you add the app within an [Click 1] individual SharePoint site as before. The app may or may not provision an [Click 2] app web, depending on whether the app includes any declarative SharePoint components. This time, the app UI and functionality are provided by [Click 3] a remote web server. This could be a web application running in a cloud platform such as Azure, or it could be web farm hosted by the publishers of the app.
When a SharePoint user [Click 4] browses the host web, the app content is provided by the remote web server and [Click 5] rendered within an iFrame on the SharePoint page.
The remote web server can run [Click 6] any code it likes, as it’s not part of the SharePoint farm. If the app and the current user have sufficient permissions, the app can use [Click 7] the SharePoint .NET client API or the REST API to interact with SharePoint.
Just like the SharePoint-hosted app model, no code runs on the SharePoint server. The user experience and the app installation process are the same regardless of whether the app is SharePoint-hosted or provider-hosted.

7. Key Features and Benefits
Platform agnostic
No custom code on SharePoint servers
Isolated app domain
Self-contained
Explicit, declarative permissions model
So let’s briefly review the key advantages of the SharePoint app model, when compared to deploying farm solutions or sandboxed solutions.
First, apps are platform-agnostic – they work the same regardless of whether you’re deploying to an on-premises installation or an Office 365 subscription.
No custom code runs on SharePoint servers – administrators don’t have to worry about customizations jeopardizing the security or performance of the wider SharePoint environment.
Every app runs in an isolated app domain – so any weaknesses in app pages are less likely to affect your SharePoint environment.
Apps are self-contained – any SharePoint artifacts go in the app web. This makes apps more reliable, as there’s no dependencies or interactions with any existing features. It also means that apps are consistently easy to remove cleanly.
Finally, apps have an explicit, declarative permissions model. When you install an app, it prompts you to grant the permissions it requires to operate. This is all or nothing – you either grant the permissions or the installation does not proceed.

8. How Do Users Interact with Apps?
Full Page (Immersive)
Client Web Parts
Custom UI Actions
Apps can support three different types of user interaction.
The first is full page, or immersive. When the user launches the app, it renders in the whole of the browser window except for the menu bar at the top.
Alternatively, apps can expose functionality through client web parts. You add the client web part to page in the host web, like you would with any web part. The client web part display content from a page in the app web.
Finally, app developers can expose functionality through custom UI actions in the host web. What happens here is that the app adds buttons or menu items, either to the ribbon or to the edit control block for files in a document library. When a user clicks the button or selects the menu item, SharePoint launches the app. This approach enables app developers to pass contextual information, such as the list item or document that was selected, to the app.

9. Where Do You Get Apps From?
SharePoint Store
App Catalog
The primary source for externally developed apps is the SharePoint Store (also sometimes referred to as the Office Store and the Office Marketplace). The SharePoint Store lets you browse thousands of apps, both free and paid-for. All the apps on the SharePoint Store are provided by verified developers and go through a quality control process before they’re made available to the public.
Within an organization, you can create an App Catalog to make apps available to SharePoint site owners. An App Catalog is a special type of SharePoint site collection that stores Apps for SharePoint and Apps for Office. These can be apps that you’ve purchased from the SharePoint Store or apps that you’ve developed in house. We’ll take a closer look at creating and using an App Catalog shortly.

10. Browsing the Office Store
Prerecorded demo DeployingSharePoint2013_M5_D1.mp4
Explain that I’m doing this from my O365 personal site as our demo environment isn’t set up for apps yet.
Browsing the Office Store

11. App Permissions Fundamentals

12. The App Permission Model
Apps request permissions at install time
Each individual permission request includes:
Scope
Permission level
Properties
Authorization policies
User and app policy
App-only policy
Keep this slide brief – following slides help to fill in the detail.
When you install an app, it requests a set of permissions. This is an all-or-nothing request – you choose to either trust the app and grant the required permissions, or cancel the installation. The person installing the app must themselves hold the permissions requested by the app – you can’t install an app that requires permissions that you haven’t been granted.
Each individual permission request contains:
A scope – i.e. which securable objects are covered by the permission
A permission level – i.e. what level of permission the app requires, ranging from full control to read
Optional properties. For example, if a permission request specifies the List scope, the properties might narrow this down to a specific type of list.
We’ll look at these in more detail over the next few slides.
Finally, an app can use two different types of authorization policy.
User and app policy means that in order for the app to perform a particular action, such as add an item to a list, both the app and the person using the app must have been granted permission to perform that action.
App-only policy means that the app can perform actions it has been granted permissions to perform, regardless of the permissions of the person using the app. For example, if you create a helpdesk app that adds requests to a list and starts a workflow, you might not want to grant all helpdesk users access to the underlying list – the user interacts with the app, and the app alone interacts with the underlying list.

13. The App Permission Model
To understand how app permissions work, it’s useful to look at things from the perspective of the app developer. When a developer creates an App for SharePoint, they specify the permissions they require in an App Manifest file. The user interface looks like this [Click].
Talk through the slide – draw on screen if possible:
E.g.
You can see here we’re requesting permissions at various scopes:
Tenant means you’re requesting access to the entire tenancy that hosts the installed app
Site Collection and Web means the site collection and individual site that host the app respectively
List means a specific list on the site that hosts the app
There are also various functionality-specific scopes, such as access to the Search service and access to the newsfeed.
For each permission request, you specify a permission level. The four core permission levels for apps are Read, Write, Manage, and FullControl. Some of the functionality-specific scopes have custom permission levels – for example, the Search scope has a single permission level, QueryAsUserIgnoreAppPrincipal.
Finally, you can use Properties to refine the scope of a permission. In this case we’re refining our List scope, so that we’re only requesting permissions on lists with a Base Template ID of 101 – in other words, document libraries.
Also point out the App-only option at the top of the screenshot.

14. The App Permission Model
Under the hood, this is a simple XML file – you can see we’ve got an AppPermissionRequest element for each individual permission request.

15. The App Permission Model
When you install an app, it describes each permission request. You’ve then got the option to trust the app – i.e. grant all the requested the permissions – or cancel the installation.

16. App Installation Permissions
To install an app on a SharePoint site, the installing user must have:
The Manage Web site permission on the host web
The Create Subsites permission on the host web
All permissions requested by the app
Make the point that by default only the Full Control permission level includes the Manage Web site permission and the Create Subsites permission. As such, by default only site collection administrators or members of the site owners group can add apps.

17. Configuring Infrastructure for Apps

18. Infrastructure Requirements
Provision a Subscription Settings Service Application
Provision an App Management Service Application
Create an app domain in DNS
Top-level domain (recommended)
Sub-domain
Configure App URLs in SharePoint
App domain
App prefix
Create an App Catalog
The Subscription Settings Service application manages tenancies within a SharePoint farm. The vast majority of SharePoint Server 2013 deployments are not going to be multi-tenant environments, so you wouldn’t bother with a Subscription Settings service application. However, because Apps for SharePoint are designed to work in any SharePoint environment, including multi-tenant environments such as Office 365, app installations need to be associated with a tenancy. As such, you need to provision a Subscription Settings service application. You can’t create a Subscription Settings service application from the Central Administration website – you have to use PowerShell.
The App Management Service application manages licenses and permissions for SharePoint apps. Any time you add an app from the Office Store (even free apps) there is an associated license, and the App Management Service tracks and manages these licenses. When you install an app you are prompted to grant the app any required permissions, and the App Management Service tracks and manages these permissions. Every time you request an app or launch an app, SharePoint calls the App Management Service to validate the request. You can create an App Management Service application using either the Central Administration website or Windows PowerShell.
Next, you need to create a dedicated domain for your apps in DNS. This can either be an entirely separate top-level domain, or a subdomain of your SharePoint domain. The best practice is to create a brand new top-level domain – such as contosoapps.com – to minimize the risk of XSS vulnerabilities.
You need to configure app URLs in SharePoint. You need to tell SharePoint what app domain to use and what app prefix to use – we’ll look at app prefixes more closely on the next slide.
Finally, in most cases you’ll need to create an App Catalog. This isn’t essential if you plan to let users download apps from the Office store directly. However, if you want to control how users request and download apps, and if you want to make apps you’ve developed in-house available, you will need to create an App Catalog.

19. Understanding App URLs
App prefix
App instance identifier
Top-level app domain
When you launch an App for SharePoint, the app URL will look something like this. There are three key parts to the app URL:
[Click 1] On the right, you have the top-level app domain.
[Click 2] In the middle, you have an app instance identifier. This is a GUID that SharePoint generates for every instance of an app – so if you install the same app on ten different sites, you’ll have ten different instance identifiers.
[Click 3] On the left, you have the app prefix. The app prefix is specific to a SharePoint tenancy. As your SharePoint environment will likely only have the one default tenancy, all your apps will have the same prefix.

20. Configuring App URLs Central Administration Windows PowerShell
Apps > Configure App URLs
Windows PowerShell
Set-SPAppDomain
Set-SPAppSiteSubscriptionName

21. Configuring Infrastructure for Apps
Part 1: Configuring DNS
Prerecorded demo DeployingSharePoint2013_M5_D2_Part1.mp4
Create a new zone
Add a CNAME (alias) record that points to the SharePoint farm host name
Part 2: Provisioning the Suscription Settings Service Application
Prerecorded demo DeployingSharePoint2013_M5_D2_Part2.mp4
We’ve switched to the SharePoint server and started up PowerShell ISE
Start the Subscription Settings service instance
Get the application pool
Provision the service application
Create the service application proxy
Part 3: Provisioning the App Management Service and Configuring App URLs
Prerecorded demo DeployingSharePoint2013_M5_D2_Part3.mp4
We’re now going to switch to the Central Administration website to complete our infrastructure configuration
Start the App Management Service instance
Provision an App Management Service application
Configure the App URLs
Configuring Infrastructure for Apps

22. Supporting Internet-Facing Endpoints
Quick tip – some apps in the SharePoint store need to be able to connect to the internet in order to work properly. If you want to enable users to install these apps, you need to enable this feature – Apps that require accessible internet facing endpoints – at the web application level. However, bear in mind that you may need to review whether or not to enable this feature in light of your organization’s governance policies.

23. Configuring the App Catalog

24. What Is the App Catalog? Specialized SharePoint site collection
Two libraries:
Apps for SharePoint
Apps for Office
Make apps available to sites within web applications
Apps developed in-house
Preapproved apps from the SharePoint Store
Enables you to control how users download and install apps from the SharePoint Store
More detail on final point: you don’t actually use the App Catalog site to control how users download and install apps from the SharePoint Store. However, if you want the option to control how users download and install apps from the SharePoint Store, you need to create an App Catalog. Once you’ve created an App Catalog, you can choose to prevent users from downloading apps directly from the SharePoint Store if you wish. We’ll look at how this works in a little more detail later on.

25. Provisioning an App Catalog
Central Administration
Apps > Manage App Catalog > Create a new app catalog site
PowerShell
New-SPSite (use the APPCATALOG#0 site template)
Update-SPAppCatalogConfiguration

26. Provisioning an App Catalog
Prerecorded demo DeployingSharePoint2013_M5_D3.mp4
In Central Admin, create a new app catalog (point out the web application association)
Browse to the site and briefly explain the three lists
Apps for SharePoint
Apps for Office
App Requests
Provisioning an App Catalog

27. Managing Apps for SharePoint

28. Configuring SharePoint Store Settings
Users Can Add Apps Directly
Users Must Request Apps
Site owner browses the SharePoint Store, finds an app, and clicks Add It.
Site owner acquires app license from the SharePoint Store.
Site owner accepts permissions and installs the app.
Site owner browses the SharePoint Store, finds an app, and clicks Request It.
Administrator approves the request on the App Catalog site.
Administrator acquires app license from the SharePoint Store.
Site owner accepts permissions and installs the app.
Once you’ve provisioned an App Catalog site, you can choose whether to allow users to add apps directly from the SharePoint Store. If you choose to prevent users from adding apps directly, they can still browse the SharePoint store, but instead of an Add It button they see a Request It button.
Talk through the two processes for adding an app.

29. Configuring SharePoint Store Settings
Prerecorded demo DeployingSharePoint2013
Part 1
We’re logged onto our team site as Francine Fischer. Francine is in the Owners group for the team site, so she has the permissions required to add apps to the site.
Part 2
We’re now logged into the Central Administration website with our SharePoint Administrator account
We can view the licenses for apps that users have installed, and remove licenses if we wish
Remember that SharePoint checks licenses with the App Management Service whenever you launch an app, so by removing the license we prevent people from using the app
We can also change the SharePoint Store settings to prevent users from installing apps directly
Part 3
We’re logged in as Francine Fischer again
Browse back to app store
Point out that you now see a Request It button instead of an Add It button
Part 4
We’re back in the Central Admin website, logged in as our SharePoint Administrator account
Browse to the App Catalog and approve the request
Point out that approving the request is not enough - you also need to get the app from the app store
Part 5
We’re logged in as Francine again
Browse to the app request, show it’s approved
Browse to Apps You Can Add and show that you can add the app
Configuring SharePoint Store Settings

30. Distributing Apps Internally
Upload .app files to App Catalog
Provide metadata to help users discover apps
Users with App Catalog permissions can browse and add apps from any Site Contents page
Explain that apps are packaged as .app files. You upload these files to the Apps for SharePoint library on the App Catalog site.

31. Upgrading Apps Upload updated .app file to App Catalog
Update metadata if required
Site owners are notified that an updated version is available
Site owners choose whether or not to install updated version
When you upload an updated app to the App Catalog, SharePoint will detect that it’s a new version of an existing app – the app’s unique ID will be unchanged. Update the metadata if required – e.g. “new in this version…”
When users launch the app, they are notified that an updated version is available. The key thing point here is that the administrator can’t force the update on site owners – the site owners choose whether they want to install the updated version or continue using their existing version.
Discussion point: is data preserved when you upgrade an app? It depends on the app – in most cases it should be. However, if for example a list schema changes radically between app versions you might lose information.

32. Distributing and Upgrading Apps
Prerecorded demo DeployingSharePoint2013_M5_D5.mp4
In this demo, we’ll take a look at how you can distribute apps that you’ve developed internally, or obtained from somewhere other than the SharePoint Store.
Part 1 – Administrator uploads .app file to App Catalog, provide metadata
Part 2 – User adds app from their Site Contents page
Part 3 – Administrator uploads updated version
Part 4 – User chooses to install updated version
Distributing and Upgrading Apps

33. Monitoring Apps Installation Source Installed Locations Errors Usage
You can monitor apps through the Central Administration website. For each app, you can see:
The installation source – in other words, whether it came from the SharePoint Store or the App Catalog
The installation locations – in other words, how many sites is the app installed on
An errors that have when installing, upgrading, or running the app
Information on the number of launches and the number of unique users over time

34. Monitoring Apps Prerecorded demo DeployingSharePoint2013_M5_D6.mp4
In Central Admin, add apps to monitor and then talk through the available information.
Monitoring Apps

35. Module Review Apps for SharePoint Fundamentals
App Permissions Fundamentals
Configuring Infrastructure for Apps
Configuring the App Catalog
Managing Apps for SharePoint