Managing 2013 Apps for IT Pros

1. Managing 2013 Apps for IT Pros Presenter: Al Carroll May 15th2013

2. Introductions CTN Dynamic is a Custom Support Organization. CTN Dynamic provides support for Microsoft SharePoint, Dynamics CRM, and GP platforms, to companies of all sizes. Our team of Level 3 Application Support Architects provides each of our customers with dedicated support of their specific environment with measurable SLAs. http://www.ctndynamic.com • Audience Poll Time Ben Carroll SharePoint Architect (and nice guy) Email: bcarroll@ctndynamic.com LinkedIn: www.linkedin.com/pub/ben-carroll/5/941/937/ (I would love feedback and questions/discussion via email)

3. Agenda Overview Where Apps fit in the SharePoint 2013 Customization Pathways? Apps Architecture Planning for Apps Apps Development App Environment Configuration App Security Data Storage and Access with Apps Monitoring Apps Demo Questions

4. Overview It’s all about the Apps (..almost)

5. SharePoint 2013 Apps Overview Apps are secure, with permissions independent of user permissions Lower risk than farm and sandbox solutions since app code never runs in a SharePoint Host Environment Easy to deploy, monitor, find, upgrade, and retire. Site owners can discover and download apps for SharePoint from a public SharePoint Store or from their organization's internal App Catalog and install them on their SharePoint sites. Not a complete replacement SharePoint features and solution packages but provide pathways for a majority of scenarios where we would've used the former. Simple lifecycle – Apps can be installed, upgraded, and uninstalled by site owners. Integrate with Office Apps Not available in SharePoint Foundation 2013

6. App User Experiences • Immersive Apps • Part Apps (App Parts) • Custom Action Apps • Branding and UI Integration • App Templates: pull CSS from hosting SharePoint Environment when creating Visual Studio Apps • Chrome Control – JavaScript based control which allows for consumption of styling of the parent AppWeb

7. The App Store Microsoft hosts and controls a public SharePoint Store. Developers can publish and sell their custom apps. End users and IT professionals can purchase apps for personal or organizational use. This SharePoint Store will manage discovery, purchase, upgrades, updates, and dispute resolution. Company-developed and approved apps can also be deployed to an organization's internal App Catalog hosted on SharePoint 2013 or SharePoint Online

8. Advantages of Apps • Advantages to Users • Apps are available through theApp Catalog or App Store • Provide easiest discovery & installation without intervention of SharePoint Admins • Apps provide upgrade support • Advantages to Administrators • Less risk than Sandboxed or Farm Solutions since they execute outside the server. • Apps are Configurable by Administrators allowing them to restrict usage of Apps • Scale App Components rather than SharePoint when appropriate • Advantages to Developers • Web Programming skills are reusable in creating Apps • Common web standards of HTML, JavaScript, CSS can be used to develop Apps • Visual Studio 2012 supports App project templates • Like Sandboxed Solutions, developers can access SharePoint objects inside Apps • Opportunity to create & publish Apps to SharePoint store

9. How are apps for SharePoint and SharePoint sites related? Site owners can add apps for SharePoint to their sites. App containing SharePoint components, store those components in a subweb of the site that is automatically created upon app installation. Apps have their own, isolated URLs, separate from the URL for the site containing the app. If the app is a Provider-hosted then components are stored in the in the cloud.

10. Where are Apps hosted? • Provider-hosted • HTML and JavaScript hosted by SharePoint Environment of Provider • Hosted in the cloud (Windows Azure auto-hosted) • Hosted in a SharePoint environment • Several combinations of these options.

11. What is the URL for an app for SharePoint? Apps by default are deployed to their own web site in an isolated domain name, separate from your farm, thus are unable to affect your SharePoint Sites. This prevents cross-site scripting between the apps and sites and unauthorized access to data. Each app install has a unique URL in your SharePoint environment. You determine the template for that URL by specifying a domain name and an app prefix, and then app URLs are automatically generated based on that template. Paths for the apps are based on the URL for the site where they are installed. Upon app installation, a subweb of that site is created to host app content. The subweb for the app is hierarchically below the site collection, but has an isolated unique host header instead of being under the site's URL.

12. Impacts of apps for SharePoint Supporting apps for SharePoint in your environment does require configuration changes to your environment. There are two main considerations: • Requirements for supporting apps for SharePoint   • Subscription Settings and App Management service applications must be running. • A DNS domain to contain the URLs for apps for SharePoint in your environment must be created. • Plan for capacity  Each app for SharePoint creates a subweb under the site on which it is installed with its own URL. Environments with lots of apps have lots of subwebs. Keep this in mind during capacity planning

13. Where Apps fit in the SharePoint 2013 Customization Pathways?

14. Custom Development Directions Farm Solutions Sandbox Solutions Apps

15. IT Pro Challenges with SharePoint Solutions Custom code running inside your SharePoint environment – risk and scaling challenges DLL Dependency – futureproofing/migration challenges Solution Permissions based on user identity – authorization challenges Not so easy to install and upgrade – Pain in the Admins never you mind just where..

16. Apps compared to Sandbox Solutions • Microsoft wants you to use App Model to most places where you would’ve used Sandbox Solutions. (Pssst… Hey buddy…. sandboxes are deprecated going forward) • App solutions can be used to deploy declarative SharePoint Objects like lists • Apps can’t do everything that farm and sandbox solutions can, but there are workarounds for many scenarios. (more on that in another slide..) • You will have to use solutions in some cases. Content type or list template available to an entire site collection would require a sandbox solution • Apps can include SharePoint Solutions but NOT server side code. • Shiny new things in Apps that aren’t in Sandbox Solutions • App Marketplace • Oauth support

17. When to use Apps vs. Farm Solutions There is overlap between the two due to the evolution of SharePoint Apps • use one of the SharePoint client object models or REST endpoints to access SharePoint content and components. These client APIs are designed for end user functionality, (site owners, site members, and tenant admins). • Apps can be installed by tenant and site collection administrators. • Since SharePoint Apps are website scoped and cannot include custom code that runs on the SharePoint server, it cannot call administrative APIs. • In general use apps for end users functionality and farm solutions for administrator functionality. Farm solutions installed by farm admins with farm, web application, or site-collection scope, and can access the server object model and run code on the SharePoint Server. Server object model has APIs enabling SharePoint management, configuration, and security, including extending Central Administration, backups, timer jobs, and PowerShell. allows manipulation of SharePoint components and end user features, but in SP2013 the design intention is to use apps unless a single solution requires both administrative and end user functionality.

18. App Approaches to Pre-App Scenarios Custom server side code running on the SharePoint servers is not allowed in SharePoint 2013 Apps, which at first glance may appear to be a big limitation BUT we can just move business logic to the client or the cloud and accomplish MOST of what you would’ve done with server side code. Use SharePoint’s REST/OData service for accessing SharePoint lists and data. Access SharePoint data remotely via JavaScript, .Net Client Object Model, or Silverlight OM. Where you would’ve created web parts in SP2010 –SharePoint apps can include remote pages with custom Web Parts or surface a page from a remote web application in an app part on a SharePoint site page. The remote page will have the same look and feel as a Web Part. An app for SharePoint can contain remote event receivers that provide the same functionality as Event Receivers and Feature Receivers. Custom web services can be created as remote services. Apps can include remote web pages that can use built in SharePoint web parts. These pages are available from every website where the app is installed and function like Application Pages.

19. Apps Architecture

20. Tenancies and App Scope “A SharePoint 2013 tenancy is a set of site collections in either a SharePoint farm or in SharePoint Online. In SharePoint Online, the site collections belong to a single customer account. In a SharePoint farm, the site collections can be all the site collections in a SharePoint web application or a subset of them, or it can be a set of site collections from across multiple web applications in the farm. A tenancy can have an app for SharePoint app catalog just as a SharePoint web application can.” -- technet An app for SharePoint has an app scope of WEB or TENANT. The difference is not an intrinsic property of the app and developers do not decide what the scope of their app has. The decision is made by tenant administrators based on how the app is installed. Web Scope: After an app is uploaded to the App Catalog of a tenancy, it is available for installation sites within the tenancy on a website-by-website basis. Apps that are installed this way have web scope. Tenant Scope applies to apps,batch installed to a subset of websites within their tenancy by Tenant administrators. The tenant admin can specify which websites the app is installed to, through a list of managed paths, site templates, or site collections. If an app that includes an app web is batch-installed, only one app web is created and it is shared by all the host websites on which the app is installed. The app web is located in the site collection of the corporate app catalog.

21. Tenancies and App Scope.. Tenancy-scoped • App installed in app catalog site • App available to multiple host webs • Host webs access one app instance • Centralized app management • Typical farms do not have explicitly created tenancies. On-premise farms can be configured with a farm-wide tenancy default. • Apps that contain a custom action for the ribbon or app parts can’t be batch installed. Custom actions that are deployed as menu items are allowed. Site-Scoped (Web Scoped) • App installed in specific site • App launched from same site • Site is called Host Web

22. Hosting Azure Auto-hosted Appsinclude a Windows Azure Web site, and possibly a SQL Azure DB automatically provisioned transparent to end user when an app is installed. Azure Web Sites infrastructure manages isolation of tenancies. You don’t have access to all Azure services like Media Services or Service Bus As with provider-hosted apps, auto-hosted apps can have SharePoint components stored in the optional app web too. Cloud hosted apps include at least once component that is hosted outside of the SharePoint farm, but they may also include SharePoint-hosted components. We break this down into Auto-hosted and Provider-hosted Provider-hosted (developer hosted)appsare hosted by the provider /developer, or even on your own separate hardware (this could be in the cloud).  Data storage , business logic, and account isolation is up to the provider or developer, Apps can have SharePoint components too, stored in an optional app web hosted in the SharePoint farm.  Provider-hosted apps provide lots of flexibility, for example being able to use any platform and programming language for your application – even non-Microsoft. SharePoint-hosted–Apps include only SharePoint components and logic that runs on the client. There are no external components and all components of the are contained within a special App Web.  The app is installed on an existing site, but it actually runs from and stores all its data within this App web, which is a sub site of the site where the App is installed. No server side code is allowed for SharePoint-hosted apps, only JavaScript calls between the client machine and farm.

23. App Webs, Host Webs, Features, and SP Components in Apps Host Web is the website where an app for SharePoint is installed. However, the significant parts of the app for SharePoint, whether they are SharePoint components or external components, are not deployed to the host web. External parts are deployed to external servers or cloud accounts. App Web is a special SharePoint Site where an App’s SharePoint components are deployed and has its own domain. A limited set of UI elements allow users access to the app's other components and are deployed to the host web as a Host Web Feature. Host Web Features are in the root app package’s XML Hierarchy instead of inside a .wsp file. Components deployed to the app web are in Features within a .wsp file. Both types of Features must have Web scope. Only these two types are allowed. Most SharePoint component that don’t include server side code running on SharePoint servers can be included in an app and deployed to the app web.

24. App Packages An app for SharePoint package is essentially cab file with an ".app" extension, containing an app manifest. App Manifests set app properties and provide SharePoint with installation instructions. App Packages meet the Open Packaging Conventions (OPC) standard. You can open the file by adding a ".zip" extension on the filename and then opening it in Windows Explorer or with winzip.

25. App Permissions Apps that use an App web, the App will have full control rights to the App web, so it will only need to request and have permissions assigned to resources in the Host web or other locations outside the App web. Apps use permission requests to specify the permissions that are needed at a particular scope.  There are different scopes that can be specified for content and in addition to these, there are also scopes for items such as performing search queries, accessing taxonomy data, and microfeed activities. App permission rights indicate the activities that an app is permitted to do within the requested scope which are also detailed in the article referenced above. Unlike SharePoint user roles, these rights levels are not customizable. Users installing apps must have full permissions on the Host web that an App is requesting. On installation the user will be notified as to what permissions the App requires. Selective delegation and authorization Neither users launching an app, nor resource owners granting an app permission to access resources, have to give an app their username or password. SharePoint 2013 use OAuth so users and resource owners to grant only the specific permissions that the app requests. Cross-domain access: An app for SharePoint that includes a remote web application that uses JavaScript for its data access logic can use a JavaScript cross domain library to get authorized access to SharePoint data within the tenancy where the app is installed. 

26. Service Applications • Two service applications required for apps • App Management Service • Site Subscription Management Service • These must be created in on-premise farms for apps to work

27. Planning for Apps

28. Plan App Configuration Settings You must explicitly configure your environment to allow apps or site owners will receive error messages when they attempt to install apps. SharePoint apps require set up of a Domain Name Services (DNS) domain name to provide a host name for installed apps. The separate domain name, keeps apps for SharePoint separate from SharePoint sites, preventing unauthorized access to user data and reducing the possibility of cross-site scripting attacks. Apps have unique URLs, consisting of the app domain plus a prefix and an Apphash. The format is: prefix-Apphash.domain.com. Apphash  is an arbitrarily-assigned unique identifier for each app for SharePoint. The App URLs are automatically created based on developer specifications. You do not have to create or manage these URLs separately; instead you configure a wildcard entry in DNS to provide the URLs for all apps. In multi-tenancy environments, admins must use the Set-SPAppDomain PowerShell cmdlet to configure the URL and prefix.

29. Plan DNS • App Isolation is using separate URLs for SharePoint apps and sites. • DNS records are required in order to correctly resolve the domain name. • Create one of two of the following types of DNS records for app for SharePoint URLs: • A wildcard Canonical Name (CNAME) record that points to the host domain assigned to the SharePoint farm. • A wildcard A record that points to the IP address for the SharePoint farm.

30. Plan SSL “Secure Sockets Layer (SSL) is a requirement for web applications that are deployed in scenarios that support server-to-server authentication and app authentication. ….. As a prerequisite for configuring Task Synchronization, the computer that is running SharePoint Server must have SSL configured.” -- http://technet.microsoft.com/en-us/library/jj554516.aspx The above sort of means if you want apps and app security you need SSL. The app model uses OAuth access tokens. These tokens contain user and app identity info which it’s safer to encrypt in order to prevent that info being intercepted by a sniffer and used to penetrate resources.. Using SSL means that you must create a wildcard certificate to use for all app URLs.

31. Domain Names and Prefixes • App Domain should be in the Internet or Restricted sites security zone in Internet Explorer • “..we recommend that you configure the app domain to be in either the Internet or Restricted sites security zone in Internet Explorer options, and not in the Intranet zone or Trusted sites zone. Internet Explorer security settings for the Intranet zone or Trusted sites zone do not provide a sufficient level of isolation of apps from user data in SharePoint sites.” --Technet • In general use unique domain names and avoid subdomains • If you use a subdomain then potentially malicious code could read or set cookies.

32. Host Headers Microsoft recommends a best practice of using a single web application with host headers rather than multiple web applications with path-named site collections in your environment. When you use multiple web applications and path-named site collections you might have to complete additional configuration steps to guarantee that requests for apps for SharePoint are routed to the correct web application.

33. Plan The App Catalog & Store The SharePoint Store is accessible to the general public. On Premise Farm Admins can configure whether users can purchase from the store. App Catalog - If you allow apps, you can configure a special site that contains the apps for SharePoint that site owners can install. Farms can support multiple App Catalogs, one per web application. To configure a web application’s App Catalog, you supply names of the site collection admins who will have approval rights. The admins can then upload apps into the AppCat. The App Catalog can be accessed from a link in Central Administration or directly by using the URL.

34. Plan Monitoring Apps • Farm Admins can monitor apps usage and errors by adding apps to the Monitor Apps page in SharePoint on-premises. • The maximum number of apps that can be monitored on the Monitor Apps page is limited to 100. • The Monitor Apps page requires search analytics and usage file import timer jobs to be running: • ECM analytics timer job name: Usage Analytics timer job for Search Service • Usage DB timer job name: Microsoft SharePoint Foundation Usage Data Import

35. Plan for app licenses SharePoint 2013 does not enforce app licenses. Developers who build apps must add code that retrieves license information and then addresses users appropriately. SharePoint 2013 provides the storage and together with SharePoint Store web services the app license renewal. SharePoint Store handles payments for the licenses, issues the correct licenses, and provides the process to verify license integrity. Note that licensing only works for apps that are distributed through the SharePoint Store. Apps that you purchase from another source and apps that you develop internally must implement their own licensing mechanisms. SharePoint 2013 supports the following app licenses formats:

36. Plan for App Governance Some basic governance questions regarding apps: Should site owners to be able to install and use apps for SharePoint at all? In which environments (intranet, extranet, or Internet) should apps to be available? Do you want to restrict or control the apps for SharePoint that site owners can install and use? Do you want to control who can purchase apps for SharePoint? Do you want to control who can install apps for SharePoint? Do you want to provide specific apps for SharePoint in your environment? Do you want apps for SharePoint from your own organization added to the App Catalog. What apps do you need SharePoint to monitor? (Apps are not monitored by default.)

37. Plan for App Permissions App permission request App permission rights • Read • Write • Manage • Full control • Tenancy • SPSite • SPWeb • SPList App Permissions manage app’s ability to access and use internal SP2013 resources and perform tasks for users. SharePoint 2013 uses the Windows Azure Access Control Service (ACS) to issue time- and scope-limited access tokens for apps. In SharePoint, ACS is the app identity provider. App Authentication verifies a claim that an app makes and asserts that the app can act on behalf of an authenticated SharePoint 2013 user. App Authorization verifies that an authenticated app has permission to access a specified resource and perform a defined action. Admins can allow a SharePoint 2013 site owner, or user with elevated permissions, to purchase and install an app that a defined set of internal SP2013 users can access.

38. App permission request scopes • SharePoint 2013 apps use app permission request scopes and permission requests to specify the level at which the app is intended to run, and the permission level that is assigned to the app. • SharePoint 2013 supports the following permission request scopes: • SPSite Defines the app permission request scope as a SharePoint 2013 site collection. • SPWeb Defines the app permission request scope as a SharePoint 2013 web site. • SPList Defines the app permission request scope as a SharePoint 2013 list. • Tenancy Defines the app permission request scope as a SharePoint 2013 tenancy.

39. App Permission Inheritance Apps follow familiar SharePoint Permissions Inheritance. If an app is granted permission to one scope, the permission also applies to the children of that scope. If an app can access a Site then it can access children of the site such as its lists and libraries. Since Apps don’t know the topology of site collections from which they request permissions, the scopes are expressed as a type and URI rather than as the URL of a specific instance. Content database related permissions are organized under this URI: http://sharepoint/content.

40. App authorization policies SharePoint 2013 provides the following app authorization policies: User and app policy authorization succeeds if both the current user and the app have permissions to perform the actions that the app is attempting. App-only policy  authorization succeeds if app has sufficient permissions, regardless of user permissions. This is required when the app is not acting on behalf of a user. User-only policy authorization succeeds if the user has sufficient permissions to perform the action that the app is designed to perform. The user-only policy is required when a user is accessing their own resources..

41. App Development Environments and Deployment

42. SharePoint 2013 Developer Tools Napa Visual Studio 2012 SharePoint 2013 Designer

43. Napa - Not just a tasty vegetable.. Essentially a cloud or browser IDE and simplified browser version of Visual Studio Office 365 Developer Sites have unlimited license One way “upsizing” to Visual Studio 2012 Does not support code behinds Client side code only

44. SP 2013 Deployment Options • On-Premise • Installed on your hardware • Access to all of SharePoint’s features • Hosted • Installed 100% in the cloud usually on Office 365 • Feature set is limited • Hybrid

45. Languages and Environments for Apps Dev • Languages • Client side JavaScript for SP-Hosted Apps • C# and VB.NET for Provider or Autohosted Apps • Local Development Environments • For SharePoint Hosted: Napa within Office 365 • For Provider or Autohosted: Visual Studio 2012, Office, SharePoint Designer • A setup guide for development environments • http://blogs.technet.com/b/wbaer/archive/2012/10/10/setting-up-a-sharepoint-2013-development-environment-101.aspx

46. Distribute with App Packages • Apps distributed using app packages • Package is a .zip file with .app extension • Built according to Open Package Convention (OPC) Standard • Same format used for Office Apps • Must contain AppManifest.xml • Package contains inner WSP for app web • Elements deployed to app web using solution package • Solution package built into app package as inner WSP • Cloud-hosted apps will not have an inner WSP unless they are implemented to create an app web • Visual Studio then generates the needed files to publish an app for SharePoint. Developers can find your deployment package in the app.publish\version folder of your projects output folder. • The folder will contain a single .app file for the application • Cloud based apps will also have any other files required for the app. • Autohosted and provider hosted apps will include files that need to be published in the host web application.

47. App Packaging and Deployment App manifest (.xml) or .app package Developer Document Sharing Office Store or App Catalog Web Page Consumers & Corporate Users Web Server (Internet or Intranet)

48. Packaging for Host Web and Autohosted Apps • Host web feature elements added at top level • Elements.xml file for each app part, custom action, and host web feature • Visual Studio adds GUID to file names • Autohosted apps packaged with extra resources • Office 365 requires resources to deploy remote webs be built in the app package as a Web Deploy Package (.web.zip) • Office 365 requires resources to create SQL Azure DB within app package as Data Tier Application Package (.dacpac)

49. Registering App Dependencies • If your app is dependent on a SharePoint capability that’s unavailable and cannot be made available on the app web, then it won’t work. • Developers can ensure that your app is not installed where the requisite services and Features are not available by registering the dependencies of the app in app manifest. The installation infrastructure for apps for SharePoint checks for prerequisites and will block app installation if any are not available. • For services, such as Excel, Access, or Visio services, the infrastructure will verify that the service is installed and licensed. • For Features, such as a Task list, the infrastructure will verify that the Feature is deployed and activated or activatable with Web Scope on the App Web • Implicitly register dependencies with permission requests in the AppPermissionRequests section of the app manifest. • Explicitly register dependencies with AppPrerequisites when your app has a dependency that is not implied by its permission requests, you register each dependency with an AppPrerequisite element in the app manifest. There are three attributes in this element; Type, ID, and an optional MinimumVersion. • If your developers forgot to do this or are unaware then this should be one of the initial places you point them when they complain that you have the environment configured incorrectly. Then make them buy you lunch.

50. Register autohosted components • AutoProvisioning is a type of app prerequisite used only with autohosted apps. It registers components of the app that need to be autohosted. When prerequisite type is AutoProvisioning, the ID attribute is not a GUID. Instead, it is one of the following: • “RemoteWebHost” (To register a Windows Azure Web Site.) • “Database” (To register a SQL Azure.) • “Autohosted app that include Windows Azure Web Site and a SQL Azure database, get a separate AppPrerequisite element for each respectively. The following markup registers both: • <AppPrerequisites> <AppPrerequisite Type=”AutoProvisioning” ID=”RemoteWebHost” /> <AppPrerequisite Type=”AutoProvisioning” ID=”Database” /> </ AppPrerequisites>” --MSDN