Export (0) Print
Expand All

SharePoint Online Enterprises App Model Management Policies and Process

 

Topic Last Modified: 2014-01-13

This document describes the policies and process that govern how subscribers to Microsoft® SharePoint® Online (SPO) for Enterprises Dedicated Plans deploy App Model-based custom solutions to the SharePoint Online environment. Custom solutions include solutions and products that are developed by third parties and code developed in-house by customers. You can deploy SharePoint solutions to any Web application in the SharePoint Online Dedicated environment (Portal, Team, Personal Sites, or Partner Sites*).

This document is for informational purposes only. It represents the features and SKUs that were available at the time of publication but it does not officially represent and may not fully match the current in-market service, nor does it guarantee future availability of any SKUs or features. For the most current information, see the SharePoint Online Dedicated on TechNet.

This document and process do not apply to the following methods of customizing a SharePoint Online environment:

  • End-user solution. A customization that is performed through a Web-based mechanism (for example, applying style sheets, XSLT and out-of-the-box Web Parts, and other SharePoint Designer declarative solutions).

  • Sandboxed solution (partially trusted code). A customization that is created by developers and that typically contains .NET–based code and dependent files that can be deployed to SharePoint site collections by the customer’s site collection administrators. SharePoint sandbox solutions that are based on server code are deprecated in SharePoint 2013 in favor of developing apps for SharePoint. You can still install sandboxed solutions to site collections on SharePoint 2013. The declarative sandbox solution is still one of the supported solution development options and it will continue to be supported.

The goal of the policies and process in this document is to ensure that App Model custom solutions deployed to the SharePoint Online environment can be operated, managed, secured, and scaled following established best practices.

SharePoint 2013 introduces a new app development model, the Cloud App Model (CAM), which reduces the need for code running on the SharePoint Server. The key benefits are two-fold: greater app deployment flexibility and backend server/service stability.

Starting in the SharePoint 2013 release, the SharePoint Online Dedicated platform supports the App Model as its default custom solution building method.

What does the App Model offer to SharePoint Online Dedicated customers?

Self service agility − Customers can deploy code based on their own project schedule with no dependency on SharePoint Online Dedicated support schedule.

Custom defined software deployment cycle and process − Since there is no server-side code running on the SharePoint Online Dedicated Farm, the customer has full control of the solution development and deployment processes. No SharePoint Online review is required.

Lower custom upgrade support cost − Separation of the platform update from the customer solution upgrade lowers the total cost of ownership for custom solution maintenance and support.

Empower developers with common Web development skills − The App Model intends to reduce the developer ramp-up time by offering a familiar Web development experience, thereby reducing dependency on knowledge of core SharePoint concepts when writing extension code.

This section presents an overview of the steps that are generally involved in the development and deployment process for the App Model solutions.

Before you start to build customer Apps, there are some governance decisions you have to make. Each decision point is supported by the SharePoint Online Dedicated platform either as part of the farm build, by using the change request (CR) process, or by using self-service configuration options, such as granting the App Catalog Site Collection Permissions. See Appendix B for a detailed App Related CR list.

For more information, see Plan for Apps for SharePoint 2013.

The following table lists roles and responsibilities involved in the design, development, deployment, management, and use of apps.

 

Tasks Roles Responsibilities

Solution Envision and Design

Solution Architect

Understand the business problem and design solutions accordingly with the supported SharePoint Online Dedicated features

Solution Development

Development Team

Use Web application standards and toolset to develop app solutions

App Package and Publish

IT Admin

Package the solution with manifest information and publish it to the App Catalog

App Usage

Site Admin

Discover, acquire, install, and launch the app

App Management and Monitoring

Site Admin

Monitoring the usage and health of the app instance, control the overall life cycle events such as deployment, upgrade, and removal of apps

All the above roles and responsibilities are performed by Customer IT teams and site users. Essentially, the architecture gives control back to the customer when building customization or exposing rich data using the SharePoint online farm.

App configuration information breaks down into two parts: Basic and advanced.

  1. Basic configuration (applies to all customers) − See SPOD 13.1 Build Guide. The following sections in the Build Guide are directly relevant to app configuration:

    Section 2.3. Network and DNS Configuration

    Use *.001dspoapp.com for the SharePoint Apps namespace (sample app domain).

    Section 11.14. Create Service Applications

    Use New-SPSubscriptionSettingsServiceApplication for the config subscription service.

    Section 11.14.1. Configure the App Management Service

    Please follow all steps in this section.

  2. Advanced Configuration (Provided on an as-needed basis for customers that require a provider-hosted app) – See SPOD 13.1 App Support Policy and Procedure Documentation.

    SharePoint Online Dedicated supports provider-hosted apps running on Azure, on premises, or on third-party hosting facilities. An Office 365 SharePoint Multi-tenancy site is used to authorize provider-hosted apps on the SharePoint Online Dedicated site. Please follow the link below to configure your on-premise farm so that you may receive configuration guidance. Since this is not a configuration unique to SharePoint Online Dedicated, there is a link to the TechNet article that you need for detailed configuration steps.

    Step 1 -- Plan the hosting environment

    ACS trust broker setup

    For a provider-hosted app to work on SharePoint Online Dedicated, the app hosting server(s) have to be able to talk to ACS in order to perform a token exchange. Customers may need additional configurations to enable this scenario (Web proxy settings, and so on).

    The specific configuration steps can be found at: How to: Use an Office 365 SharePoint site to authorize provider-hosted apps on an on-premises SharePoint site.

The SharePoint Online Dedicated platform facilitates two broad approaches to hosting your apps for SharePoint: SharePoint-hosted and Provider-hosted. For the Provider-Hosted model, the hosted location can either be on premise Web servers, third-party hosted servers or Window Azure servers. These are not exclusive categories: An app for SharePoint can have both SharePoint-hosted and remotely hosted components. Each approach has key features you should consider when deciding how to host your apps.

The table below is a high level summary of hosting options. For detailed descriptions of each option and design considerations, please see the following articles.

Hosting Options Comparison

Hosting Model

App Location

D Support

Description

Pro

Con

Sample Code

SP hosted App

SharePoint Farm (SharePoint Online Dedicated)

Yes

Reuse SP Web elements (list, SP pages, OOB Web parts), client side technology, declarative workflow, custom actions,

BDC model)

Simple to deploy

No extra server required

Build in authentication

Full fidelity between SPO-MT, SharePoint Online Dedicated and on prem farms

Limited to client-side code, no server-side code is allowed;

Limited processing power and functionality (caching options, server process, and so on.)

Sample Link

How to:

Create a basic SP hosted app

Provider Hosted App

On Premise Server

Yes

Server side code runs on customer on premise servers or 3rd party hosted servers. Customer has full control on how to scale.

Support server code

Create just like your Web application that is not using SharePoint.

When working with SharePoint, get remote events from SP using CSOM/REST + Oauth

Provider hosted app can still have SP elements included, essentially include SharePoint hosted components as part of the solution (see above)

Requires Additional UI design consideration for SP integrated experience

Requires OAuth integration when working with SP data

Sample Link

Provider Hosted App

Azure Server

Yes

Server side code runs on Azure server. Customer can leverage Azure PAAS or IAAAS and other capabilities within the Azure Stack (connectivity, caching, ACS, Web sites, storage, and so on). Infinite Cloud scale.

Same as above

Sample Link

Auto Hosted App

Not Supported

O365 SP-MT only feature. MT tenancy controlled Azure Web and SQL Azure. Customer has the integrated experience, but does not have control of the provisioning process

Simple

Fully integrated Experience

No control of scalability and there are some Azure option limitation

NoteNote:
SharePoint Hosted Apps on SAML Web applications are not currently supported.

How does SharePoint Online Dedicated support the Provider-hosted Model?

A SharePoint Online Dedicated farm trusts the ACS instance associated with a customer’s own subscription. ACS then acts as a common authentication broker between the SharePoint Online Dedicated farm and the app and as the online security token service (STS). ACS generates context tokens when the app requests access to a SharePoint resource.

For information regarding setting up the ACS trust broker, see How to use an Office 365 SharePoint site to authorize provider-hosted apps on an on-premises SharePoint site.

For a provider-hosted app to work on SharePoint Online Dedicated, the app hosting server(s) have to be able to talk to ACS in order to perform token exchange. A customer may need additional configurations to enable this scenario (for example, Web proxy settings, and so on).

Configure Provider Hosted Model is a related CR: SPOD-13-204.

Description: Configure support for the provider hosted apps using ACS as the trust broker. This configuration applies to both customer-created apps and SharePoint App Store apps.

If you decide that your app is using the Provider Hosted model and you are hosting it within your own data center Web servers or some other application hosting infrastructure under your control (for example, Windows Azure), please submit the change request for the SharePoint Online Dedicated team to configure provider hosted app support. This is a one-time only configuration that supports all your provider hosted apps.

NoteNote:
A high-trust app is a provider-hosted app for SharePoint for use on-premises, which uses the server-to-server protocol (S2S). SharePoint Online Dedicated does not support S2S protocol for provider hosted apps.

The support for different types of Apps is the same across SharePoint Online Multi-Tennant, Dedicated and on premise. For detailed documentation, please review Accessing App from UI.

For more information please see the following:

App Types Sample Code

Type Use Case Description Sample Code Host Location

Immersive (Full Page App)

LOB integration Application hosted on SP, rendering data from SAP

Launch Full Page App

Link

Link

Host Web

App Web

Remote Web App

App Part (client part)

Reusable components such as weather, news parts that can be embedded with Host Web pages

It is a type of Web Part that is represented by the ClientWebPart class. It is deployed to the host Web, it is essentially a wrapper for an IFrame that would host a page of the app.

Link

Host Web

SP Extension

ECB action

Ribbon Action

Custom navigation link to lead to custom solution

Link

Host Web

App Web

SP Elements

Site Columns

Content Types

Modules

Workflow*

Field Type

List Definition

SharePoint Declarative Elements

Link

Host Web*

App Web

(see Host Webs, app Webs, and SharePoint components in SharePoint 2013)

Combination of the above

A composite App includes various elements above

Beyond using list data, you can also interact with search, taxonomy, social and profile data in your app or create mobile apps

Link

*Declarative workflow can only run within the app Web.

The app authentication in SharePoint 2013 is separate from user authentication and is not used as a sign-in authentication protocol by SharePoint users. App authentication uses the Open Authorization (OAuth) 2.0 protocol and does not add to the set of user authentication or sign-on protocols, such as WS-Federation. App authentication and OAuth do not appear in the list of identity providers.

The authorization policy determines whether the app access SharePoint resources based on current user’s context, app’s security context or a combination of the two. SharePoint Online Dedicated supports User-only, App-only and user+ app policy. See App Authentication Policy for supported authorization policy details and usage guidance.

Sample code: make APP only policy type calls in your App.

An app for SharePoint has its own identity and is associated with a security principal, called an app principal. Like users and groups, an app principal has certain permissions and rights. The app principal has full control rights to the app Web so it only needs to request permissions to SharePoint resources in the host Web or other locations outside the app Web.

For detailed app permission consideration and design guidance, please see App Permissions.

SharePoint App Permission Request Scope URIs and Descriptions

Scope URI Permission SharePoint Online Dedicated Support

site collection

http://sharepoint/content/sitecollection

Read, Write, Manage, FullControl

Yes

Website

http://sharepoint/content/sitecollection/Web

Read, Write, Manage, FullControl

Yes

list

http://sharepoint/content/sitecollection/Web/list

Read, Write, Manage, FullControl

Yes

tenancy

http://sharepoint/content/tenant

Read, Write, Manage, FullControl

No*

http://sharepoint/social/tenant

Read, Write, Manage, FullControl

No*

http://sharepoint/social/core

Read, Write, Manage, FullControl

No*

http://sharepoint/social/microfeed

Read, Write, Manage, FullControl

Yes

http://sharepoint/taxonomy

Read, Write

Yes

http://sharepoint/search

QueryAsUserIgnoreAppPrincipal

No*

http://sharepoint/userprofiles

Read

No*

http://sharepoint/bcs/connection

Read

Yes

NoteNote:
*These rows require FARM admin permission on SharePoint Online Dedicated farm. Since SPO cannot grant farm admin permission, the above permission request scope for self-service deployment is not currently supported.

For more information, please see the following:

Beyond the app’s own permission and policy, App Catalog Admin can also control who or what site can install the apps. See the package section later in this document for more details.

For building an on premise SharePoint Online Dedicated farm for development or integrated testing purpose, please refer to the 13.1 build guide for SharePoint Online Dedicated farm build instructions. In addition to the build guide, if you want to set up the provider hosted app support, you need to follow the set up ACS trust guidance to create the SharePoint Online Dedicated compatible environment. In addition, you can follow the article on setting up App Development Support for configuration guidance.

SharePoint Online Dedicated offers a Pre-Production Environment (PPE) that customer IT Pros can use to perform the integration test on a SharePoint Online Dedicated farm and to verify that all configuration settings are working. When deploying an app to a SharePoint Online Dedicated environment, there may be additional network connectivity and DNS configuration required. The PPE environment is intended to help you identify those required configuration and validate settings before deploying to Production.

Unlike full-trust solution development, it is not a requirement to first deploy an app to SharePoint Online Dedicated PPE before production. Developers may choose to develop directly in the SharePoint Online Dedicated production farm using a developer site collection, which fully isolates an app from all other site collections. For more information on this alternative model, see the Developing apps for SharePoint on a remote system topic. Ultimately, organizations should chose the developer model and SDLC that best fits their business.

One of the new features of the App Model is that you can actually develop App Model solutions on the client machines without having the full SharePoint farm installed on the developer box. This offers great portability, developer agility and simplifies your development environment support cost. If you work with a remote installation, you need to install the client object model redistributable from SharePoint Client Components on the target installation.

Developer Tooling Support

Tool Development Publish App to SharePoint Online Dedicated Download Link

Visual Studio 2012 + SharePoint Developer Tools

Yes

Yes

http://msdn.microsoft.com/en-ca/office/apps/fp123627.aspx

NAPA

Yes *

Yes

http://msdn.microsoft.com/en-ca/office/apps/fp123627.aspx

SPD

YES (Declarative Workflow)

No

NoteNote:
*NAPA is a Web-based IDE that supports SharePoint hosted app development. You can use NAPA and export the app package to Visual Studio 2012 for further development.

Before you start developing apps, it is recommended that you go through these articles to get familiar with designing SharePoint apps. It covers a wealth of topics such as App Manifest, data access, user identity interaction, add SharePoint feature to your apps, localization, and so on. In particular, if you are an app architect, it is recommended that you think about the app tiered design options (UI, Business Logic and Data Layer allocation).

App development for SharePoint Online Dedicated follows the same principal as app for SharePoint 2013. There are various MSDN and TechNet articles addressing API selection, Data access considerations, and so on. Notice that SharePoint Online Dedicated does not support customer SQL DB hosted within a SharePoint Online Dedicated farm infrastructure. SharePoint Online Dedicated is NOT supporting the Autohosted mode; therefore, Azure Blob storage is an option for storage.

Apps can have dependencies. Please see Registering app dependencies in SharePoint 2013 for some general guidance. Be aware that not all services are supported on SharePoint Online Dedicated platform. Please refer to the Service Description for supported dependency services.

In SharePoint 2013 there is a new site template called Developer Site Template. The site template is available under the Collaboration Site template type. This is the only target site collection that apps can be deployed from Visual Studio 2012 directly without install in the App Catalog site first.

Before you begin the development process, refer to the following.

This guide focuses on deploying apps for the App Catalog. Please see Publish apps for Office and SharePoint for App Store App development for additional details.

For a Provider hosted app to be able to interact with SharePoint 2013 using OAuth, an app must first have an app identity. To deploy to SharePoint Online Dedicated farm, developers must get an app identity for their app by registering their app. When you register your app, SharePoint generates the client ID, the client secret to assign to the corresponding App display name, and the app domain. Optionally, you can enter a redirect URI associated the app when registering your new app. In some cases, it also gets a redirect URI associated with it. After you've registered your app, your app has an app identity and is associated with a security principal.

During the development process, Visual Studio 2012 and SharePoint development tools in Visual Studio 2012 can create a temporary app identity for use during the app development. But in order to deploy an App to an integrated environment (customer farm or SharePoint Online Dedicated farm), register Apps by using the appregnew.aspx Page. For detailed technical information, please refer to Guidelines for registering apps for SharePoint 2013.

Before you build your provider hosted app, you have to generate an app ID, app secret. To generate and create these values, go to http://[SharePointServerName]/_layouts/15/appregnew.aspx.

Because SharePoint Online Dedicated had configured trust with Azure ACS, the same App ID/Secret works across SharePoint Online Dedicated prod, PPE and DR farms. Developers only need register once from one of the farms and include the ID in the package, and the same package can be deployed across PPE/PROD and DR farms. If you chose develop and test SharePoint apps in an on-premises environment first, you need to do some repackaging work to incorporate the SharePoint Online Dedicated App ID and Secret key before moving the app to SharePoint Online Dedicated.

Screenshot for AppRegNew page:

AppRegNew

If you choose to publish your provider-hosted app from the Visual Studio 2012 UI by using the Visual Studio publish wizard, Visual Studio prompts you for a client ID and client secret during the publishing process and it puts the information in the correct place for you.

In the Publish dialog box, choose Publish. The resulting app package file (which has the Windows Azure Web Site package inside) has an .APP extension and is saved in the app.publish subfolder of either the bin\Debug or bin\Release folder of your Microsoft Visual Studio 2012 project.

For detailed description of Visual Studio Features supporting SharePoint development, please see What's new in SharePoint development tools in Visual Studio 2012

Alternative to using publishing wizard, you can also modify the configuration and manifest files yourself based on the generated IDs from the appregnew.aspx page. You must acquire these IDs from the target environment. The IDs for SharePoint Online Dedicated PPE, Production and DR are all the same.

The following is an example of how the ClientId value is used in the AppManifest.xml file:

<AppPrincipal>
    <RemoteWebApplication ClientId="a044e184-7de2-4d05-aacf-52118008c44e"/>
  </AppPrincipal>

In the Web.config file in your Visual Studio project, enter the app ID value as the ClientId value.

<appSettings>
    <add key="ClientId" value="a044e184-7de2-4d05-aacf-52118008c44e" />
    <add key="ClientSecret" value="w7om5dfhzr7k5rnnA551GGp6k6z6XHprjoN8VPm6xFw=" />
  </appSettings>

The following is an example of how the values are used in the Web.config file of a Web application:

<configuration>
...
<appSettings>
<add key="ClientId" value="a044e184-7de2-4d05-aacf-52118008c44e" />
<add key="ClientSecret" value="l0z/8TzWN0yQBzMBSEZtYts2Vt3Eo/oE3rfCdPaogKQ=" />
</appSettings>
...
</configuration>

You can use Visual Studio to deploy and debug apps on your own farm for testing purpose. If you use Visual Studio to deploy to other site templates, you encounter the following error during deployment: Install app for SharePoint: Sideloading of apps is not enabled on this site.

For deploying to the SharePoint Online Dedicated PPE/PROD environment, please use the publishing wizard or your own integrated build procedure to generate the .app package, then upload the .app package, which contains the specific farm generated ID and Secret to the App Catalog site for deployment. Once the app package is uploaded, it is available for installation in the target farm. SharePoint Online Dedicated farms (PPE, PROD and DE) share the same app ID and client secret for the same app.

  1. Log in to the Microsoft SharePoint Online Farm (PPE or PROD).

  2. Navigate to the corporate catalog site pre-created for your Web application.

  3. On the App Catalog page, choose the upload link, browse to your app for SharePoint package on the Add a document form and choose OK. An item property form opens.

  4. Fill out the form as needed and choose Save. The app for SharePoint is saved in the catalog.

  5. Navigate to any Website in the Web application and choose Site Contents to open the Site Contents page.

  6. Choose Add an App, and on the Add an App page, find the app. If there are too many to scroll through, you can enter any part of the app title (that you entered for Title in the AppManifest.xml file) into the search box.

  7. When you find the app, choose the Details link beneath it, and then on the app details page that opens, choose Add It.

  8. You are prompted grant it permissions. Choose Trust It in the dialog box.

  9. The Site Contents page opens, and the app is listed. For a short time a message below the title indicates that it is being added. When this message disappears, you can choose the app title to launch the app. (You may need to refresh the page before the message disappears.) In the continuing example of this article, because the Start Page was set to the URL of the remote Web application's Default.aspx page, that page opens.

In order to deploy the app packages, the IT Admin should have proper permission to the App Catalog site (/sites/appcatalog) as the member of the site Owners or Designers group for the App Catalog. The catalog site admin can choose to grant additional permissions for delegated management tasks.

An app for SharePoint has an app scope. The two possible app scopes are Web scope or tenant scope. In a SharePoint Online Dedicated farm, the tenant case under this context is the Web application host of the catalog site. The difference is not an intrinsic property of the app and you do not decide what the scope of your app is. The decision is made by IT administrators and it is determined by how the app is installed. After an app is uploaded to the app for SharePoint App Catalog of a tenancy, it is immediately available to be installed on Websites within the tenancy on a Website-by-Website basis. Apps that are installed this way have Web scope. Customer IT administrators have another option. They can choose to batch install the app to a subset of Websites within the tenancy. Apps that are installed in this way have tenant scope. The tenant admin can specify which Websites the app is installed to by means of a list of managed paths, a list of site templates, or a list of site collections. You can batch-install an app after you install it at the catalog site and use the deploy button to deploy to various filtered target sites.

If an app that includes an app web is batch-installed, only one app web is created and shared by all of the host web sites on which the app is installed. The app web is located in the site collection of the corporate App Catalog.

A batch installed app can be removed by uninstalling it from the catalog site. For batch deployed apps, each target site collection user can see the app. When a user clicks the app launch link, they are routed to the App Catalog site, which is the host Web for the shared app.

Remember, uninstalling applications for SharePoint instances must be clean− everything installed by the application must be uninstalled with no artifacts left behind.

Note that even though an app is deployed as a tenant scoped app, if site owners can see the app, they can still install the app within their own site. In that case, you see two app links within the site: one is called shared, and the other is the site collection hosted instance.

There are also some additional limitations on what kind of apps can be batch-installed. For details, please see Tenancies and deployment scopes for apps for SharePoint .

App Catalogs are created for each Web application (for example, http://[Web application name]/sites/appcatalog). App Catalog sites can only be accessed by customer IT admins who have a Web application policy that grants explicit Full Control rights to all site collections in a Web application. IT admins who have rights may use the standard site permissions UI to grant additional access to users. Users must be given read permission in order to browse the App Catalog from their site collections. You can use permissions to control which users can see the newly deployed apps and install them on their own site. See Configure App Catalog Site for details.

Once the app is available in the App Catalog, end users can search for them in their own site collections. For more information, see Manage the App Catalog in SharePoint 2013 for details on how to add apps and remove apps from the App Catalog.

App Catalog admins can also perform app store purchase request management tasks within the catalog site. In addition to request management, the license management delegation is also managed within the site. See App Request management section under the App Catalog Site management article for details.

NoteNote:
Additional app license management features may be supported in the coming releases.

From the App Catalog site, the admin can manage store app license assignment. See Monitor and manage app licenses in SharePoint Server 2013 for details regarding app license management.

App Catalog site permission and features

On SharePoint Online Dedicated, there is an App Catalog for each Web application (team, portal, mysite). Therefore, apps are targeted at each Web application. You can assign separate owners to manage each Web application’s corporate App Catalog site. As the catalog administrator, the user can manage app purchase request, license allocation, license delegation, purchase store apps or deploy internal apps so they are available for each site collection owner to install within their own site collection. The Catalog admin can also deploy a tenant scoped app which means that the App Catalog admin can choose to deploy the app at the centralized location and make the app accessible to many site collections. The App Catalog admin can also deploy upgrade apps by deploying a new version. All site collection owners can then deploy the latest version within their sites. App Catalog owners can remove apps from the available app list by uninstalling the app. No new instance can be deployed after an app is removed from the App Catalog.

Once the app is deployed at the site collection, the owner of the site collection can monitor the usage and any error associated with the app. The usage data is collected on a daily basis.

By default, a SharePoint Online Dedicated farm is configured to support app store purchase. If your organization wants to turn it off, you can request this using the CR process.

Related CR: SPOD-13-202 App Store Settings.

Description: This request disallows site collection admins to install a SharePoint App Store App on their own site. By default, site collection admins can install apps directly. You can file this CR so that all app store app installations have to go through the app request management process. Your App Catalog Admin approves the app purchase requests before an end user can install the app. Customers can build a custom workflow to handle the app request approval process.

Please use CR SPOD-13-202 App Store Settings to require users to get an App Catalog admin before they directly install the apps from the store.

An update to an app is deployed in app for SharePoint packages in the same way that the first version of the app is deployed. The app for SharePoint update process ensures that the app's data is preserved if the update fails for any reason. For an update, you use the same product ID in the app manifest that you used for the original version. The version number in the app manifest should be greater than the version number of the original app or the most recent update. There are additional consideration when planning upgrade, such as data migration and compatibility. For the complete guidance, please see App for SharePoint update process .

Please see Add troubleshooting instrumentation to an app for SharePoint for more information regarding how to use UI to perform trouble shooting and instrumentation support. The IIS-ASP.net level tracing can only be configured at the app hosting location (customer app servers, Azure). SharePoint Online Dedicated has its own monitoring in place and can not be customized. For customer trouble shooting tips, please review the trouble shooting section.

This section describes the policies established by Microsoft for custom solution deployments to the SharePoint Online service.

SPOD App Model Solution Policy Deployment Paths

Solution Source Solution Target

On Premise SPO-D Build Farm

SPOD PPE Farm Developer site(s)

On Premise SPO-D Build Farm

SPOD Prod Farm Developer site(s)

SPOD PPE Farm Developer site(s)

SPOD PPE Farm App Catalog Site(s)

SPOD Prod Farm Developer site(s)

SPOD Prod Farm App Catalog Site(s)

On Premise SPO-D Build Farm

SPOD PPE Farm App Catalog Site(s)

On Premise SPO-D Build Farm

SPOD PROD Farm App Catalog Site(s)

For app development, it is not required that customers build an On Premise farm following our build guide. Customers can instead use Developer Sites in production to create and test apps before deploying to the production App Catalogs.

App Catalog sites are created as part of the standard SharePoint 2013 SPO-D farm build. Customers can create their own developer site collections with the Developer Site template. Note that for upgrade customers, 2013 site creation must be enabled to access this new SharePoint 2013 site template.

Follow the SharePoint 2013 published software boundaries

Recommended Guidelines for Web Apps

Limit Maximum value Limit Type Notes

Apps displayed in Manage Licenses page

2,000

Boundary

Up to 2,000 apps (purchased from the store) can be displayed on the Manage Licenses page. You can still manage the license of any app by going to the All Site Contents page of the site where the app is installed and clicking on Licenses, or by searching for the app using Marketplace Search.

Number of app licenses per tenant

1,000,000

Supported

The maximum supported number of licenses (purchase of apps from the store) for a single SharePoint deployment, either on-premises or SharePoint Online. Exceeding this limit might cause severe performance degradation.

Number of apps displayed in the Add an App page

240

Boundary

After this limit is reached, only the first 240 apps are displayed, and a message guiding you to search to find your app is displayed.

Number of managers per app license

30

Boundary

Only 30 people can manage a license. License managers can add or remove users or delete a license.

Number of app licenses assigned to a user viewable by that user

2,000

Boundary

When more than 2,000 licenses are assigned to a user, that user no longer sees any apps in the default Add an App view. Instead, a message guiding you to search the App Catalog or the SharePoint Store is displayed.

Number of apps in the corporate catalog viewable by a single user

500

Boundary

When more than 500 apps from the corporate catalog are available to a single user, that user no longer sees any apps in the default Add an App view. Instead, a message guiding you to search the App Catalog or the SharePoint Store is displayed.

The severity levels assigned to incidents caused by non-functional apps in Production are defined in the Support Service Description. As the apps are sequestered to a separate Web application that is hosted locally or remotely, the impact to the SharePoint farm is limited. If an app impacts the stability and service uptime levels of the SharePoint Online farm, Microsoft might remove the app from the catalog to contain the impact.

If an app is having production issues, customer IT admins can remove the app from the catalog to prevent it from being further deployed. Customer is responsible for the deployment and removal of the app.

In case the app has already been deployed to site collections, each site collection admin can monitor the app instance usage, view error information and uninstall the app.

NoteNote:
For the current release, there is no ability for batch removal of apps installed in many site collections.

With the new App Model, the server code and the core solution logic are running either on the client side or hosted on the application server. SharePoint Online Dedicated continues to monitor the health of the farm to ensure you have a healthy farm to support your solution. The customer needs to monitor the health, performance and capacity of the application servers hosting your app. The specific monitoring tool and process varies depending on the Web application implementation. For more information about Microsoft Web application stacks, see the following:

For reasons of confidentiality, it is the policy of Microsoft not to provide ULS, IIS, application, security, and system logs to customers. If you have an issue affecting your deployment environment, the resolution of which may require examination of log contents, SharePoint Online provides assistance when you do the following:

  1. Submit an SR for the issue.

  2. Provide detailed steps so that Microsoft can reproduce the issue.

Microsoft then makes use of the appropriate log information to resolve the issue.

We support SharePoint App Store Solutions. For details, please see Hosting options for apps for SharePoint on how to deploy App Store Apps.

  • This content cannot be displayed in a frame error − This error is caused by cookie sharing across different IE Zones. For more information, see http://support.microsoft.com/kb/2643142.

  • Multiple login prompts when using the app − To prevent this issue, please add the following App Management URL domains to your local intranet zones:

    *.ppexxxdspoapp.com to local intranet sites

    *.xxxdspodapp.com to local intranet sites

    Where xxx is a unique number assigned to each customer. See the IT requirements doc.

  • SAML claim authentication − SharePoint hosted apps are not supported on Web applications that use SAML claim authentication.

  • The specified application identifier [cbd25585-947e-4b9d-8686-ed695101ed9a] is invalid or does not exist − Resolve this issue by creating the ClientID and ClientSecret using the _layouts/15/appregnew.aspx page in your target farm. You need to register your app on the target SharePoint farm where you intend to deploy your app. You can then use the generated ClientID and ClientSecret while packaging your app in your development environment. For SPOD, PPE, PROD, and DE farms, share the same ACS instance. This way, the same APPID/Secret can be used in the same package across three farms.

  • App removal − When you remove an app, you are not only uninstalling the app itself, but the whole app web and the content it contains.

  • App permission request scope − See App Permissions for details.

  • Aggregated app monitoring view is not supported − Site collection admins can go in each site collection to view app instance usage. At the central admin level, registering an app to monitor and view total instance installed and their aggregated usage, monitoring.

  • Apps for Office may not start if you disable protected mode in the Internet zone in IE − For more information, see http://support.microsoft.com/kb/2761180.

  • Batch removal of apps from multiple site collections− PowerShell is used to support batch operations for on-premise farms. Currently, SPO does not offer this feature. For more information, see Remove app for SharePoint instances from a SharePoint 2013 site.

SharePoint 2013 Best Practices

App upgrades must have incremented versions to enable existing users the ability to download the new version. Versions are in this format: 1.0.0.0.

If you do not increment the version in the new upgrade XML file within the app package, no one is able to download the new app to their site.

For an app hosted on SharePoint, the authentication and the authorization is not an issue, because all your app resources (pages/lists) are stored in the app-Web scope and SharePoint Online takes care of it. However, for the Provider-hosted and Auto-hosted apps, the app resources are stored either on the developer hosted server or on Antares (Azure). You need protect them yourself and deal with situations when access is needed to the host Web resources. Therefore, the authentication and authorization considerations are important when using these two types of hosting method.

Apps are a new concept for SharePoint 15, empowering end users to add new functionality to their sites while still ensuring security and reliability for the SharePoint site itself. Creating a good app requires not only just making awesome functionality (although that’s obviously important), but also ensuring that the app looks right and fits seamlessly into the site where it’s installed. SharePoint Online Dedicated provides several ways to make your UX follow the SharePoint Online Dedicated style:

Use this procedure to add Chrome controls to your page.

  • Add the following reference to the JavaScript:

    https://....../_layouts/15/sp.ui.controls.js;
    
  • Add the following div section in your page content:

    <div id='chromeControlContainer'></div>
    
  • Set the options in your JavaScript.

  • Set the host site URL dynamically in your code because you do not know where the app installed during your development.

For CSS, you need to reference defaultcss.ashx in your page. You need to find the host Web URL and then use this URL when you generate the HTML. Remember that this does NOT guarantee the change on the theme when the host Web’s theme changes as the CSS is cached by the browser.

Logging and tracing is very important for every app during the troubleshooting. SharePoint Online has provided an API for logging custom errors. Developers can use a provided client-side object model API to report errors in their code to the administrator.

This API could be used in all of the hosting methods. The Site Collection Admin could use the monitor callout to check the runtime errors like below:

The App Callout

appcallout b3467c19-eb92-4641-882d-8a9d332f5f18

For the CSOM API, you need to use OAuth to communicate back to the SharePoint site to make the API call. To do this, use the following steps:

  1. Get the refresh token from the context token

  2. Use the refresh token to get the access token

  3. Use the access token to get the client context

  4. Use the client context to call the Logging API

You have to update an app for SharePoint if you add functionality, fix a bug, or make a security update. An update to an app is deployed in app for SharePoint packages in the same way that the first version of the app is deployed. The app for SharePoint update process ensures that the app's data is preserved if the update fails for any reason. Please review App for SharePoint update process for the basic concept of the app upgrade.

For the SharePoint-hosted apps, if you have defined module files in the app Web, you need:

  1. Add the ReplaceContent attribute to replace the contents of existing files during upgrade, like below:

    <Module Name="Module1">
        <File Path="Module1\someFile.txt" Url="Module1/someFile.txt" ReplaceContent="TRUE" />
    </Module>
    
  2. Also add an Upgrade Actions section in your feature.xml for which ElementManifests to run on upgrade like below:

    <UpgradeActions>
        <VersionRange EndVersion="2.0.0.0">
           <ApplyElementManifests>
              <ElementManifest Location="Module1\Elements.xml" />
           </ApplyElementManifests>
        </VersionRange>
      </UpgradeActions>
    

Also, if you have Client Web Part defined in the app Web, you need to keep the feature ID the same as a previous version to make sure it’s not deleted after the upgrade.

If the app is provider-hosted, you provide the update logic for all the non-SharePoint components of the app. This logic can go in the Post Update Web service or in first run after update logic of the app itself.

Troubleshooting App Model Development in SharePoint Online Dedicated environments can be broadly divided into three distinct categories - basic App Model trouble shooting, HTTP trouble shooting and CSOM trouble shooting. For each of these categories, knowledge of Web development principals, techniques and tools is required along side a firm understanding of the SharePoint App Model development process (see Build Apps for SharePoint).

App Catalogs are used by the SharePoint App Model as a repository for available apps that can be deployed throughout the environment. You can perform basic troubleshooting of the App Catalog to identify and resolve a number of potential issues, such as the following:

  • Are you seeing inconsistent behaviors between Web applications? Each Web application uses a different App Catalog which may lead to different apps being available at different URLs. If you are seeing inconsistency of app availability across different Web applications, consider uploading the required apps to the App Catalog defined for each Web applications.

  • If some users cannot see specific apps, they may not have access to the App Catalog site collection for the Web application or item level security may be preventing them from accessing specific items from the App Catalog. Verify the users who are attempting to add the app has access to the App Catalog site collection via the SharePoint permissions check.

  • If you have chosen to allow apps to be added to your SharePoint environment from the SharePoint store, you may need to manage the licenses associated with these apps. Typically, one or more license managers are assigned to handle these activities. It is important that you maintain adequate licenses for the each app to support your usage patterns.

  • From time to time it may be necessary to monitor app usage, runtime errors or upgrade errors. As a site collection owner, from the site apps usage page, you can see the total number of app instances and any potential errors they may have encountered during installation, during runtime or while upgrading. From the app error list you can determine if you want to remove the app because there are too many errors or the app is not working as expected.

Occasionally, it may be necessary to use tools outside of SharePoint to inspect, detect and correct errors in apps or the supporting technologies required to operate apps successfully. These tools can help inspect the flow of HTTP requests and responses from the client machine between either the SharePoint Online Dedicated SharePoint host Web and app Web or the SharePoint Online Dedicated SharePoint host Web and provider hosted app Web. One such example of these tools is the Internet Explorer Developer Tools (see Discovering Windows Internet Explorer Developer Tools ).

When trouble shooting apps, the network captures performed via the Internet Developer Tools can provide a great deal on information about the app behavior and cross Web communications. To start a network capture using the Internet Explorer Developer Tools, navigate to the Network tab within the developer tools and click on Start Capture. Now access your app and begin to visualize the http request and responses being made during app execution. Stop the capture once your app has loaded and executed. Once a capture has been gathered, verify that the HTTP requests and responses are as expected, in particular pay attention to the HTTP status codes. With the exception of initial authentications request handshaking, status code 401 warrants further investigation. Status codes in the 500s indicate an app or Web problem and should be investigated.

A significant number of App Model developments utilize the SharePoint Client Side Object Model (CSOM) and in turn, a high proportion of the CSOM used by apps uses JavaScript. Knowing how to trouble shoot JavaScript code is a valuable trouble shooting skill.

By using the Internet Explorer Developer Tools, app developers can inspect, interact and debug JavaScript scripts and functions in real time.

 

SCL Type SCL SubType Config # Description Configuration Name

App Model

App Store Request Setting

 SPOD-13-202

Specify whether end users can get apps from the SharePoint Store. This is disabled by default.

Allow Site Owners to install apps directly from SharePoint Store

App Model

Configure ACS Provider Hosted apps

SPOD-13-204

Configure a provider-hosted app which uses ACS as the trust broker.

Configure ACS

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft