SharePoint 2013 - Configure an environment for SharePoint 2013 Apps

In this post we will see the various steps required to configure the environment for SharePoint 2013 apps.

For viewing the SharePoint app store, select Add an app link and click on SharePoint Store to view all available apps.

If the app environment is not configure, then you might run into an error stating that "Apps are turned off" as shown in the following figure.

Following are the steps to configure the environment for SharePoint 2013 apps:
1) Create a forward lookup zone for apps
2) Link the App Domain to the SharePoint Server
3) Start the required Services
4) Create the Subscription Settings and App Management Service Applications
5) Configure the App URL’s in SharePoint
6) Test the App environment

Now lets see each of the above mentioned steps in detail.

1. Create a forward lookup zone for apps

SharePoint 2013 Apps have their own, isolated URLs, which are separate from the URLs of the sites where the app is being deployed to and where the app is being used. In order to provide isolation apps should run in their own domain, instead of in the same domain name as your farm. Using a different domain name for apps helps prevent cross-site scripting between apps and SharePoint sites.

Microsoft recommends that the new domain name should NOT be a subdomain of the domain that hosts the SharePoint Sites. For example, if the SharePoint sites are at home.com, consider homeapps.com instead of app.home.com as the domain name.

Verify that the user account that performs this procedure is a local administrator on the domain controller.

Click Start, point to Administrative Tools, and then click DNS.

In DNS Manager, right-click Forward Lookup Zones, and then click New Zone….

In the New Zone Wizard, click Next.

In the Zone Type page, accept the default of Primary zone, and then click Next.

In the Active Directory Zone Replication Scope page, select the appropriate replication method for your environment (the default is to all DNS servers in this domain), and then click Next.

In the Zone Name page, in the Zone name box type the name for your new app domain name (for example, homeapps.com), and then click Next.

On the Dynamic Update page, select the appropriate type of dynamic updates for your environment (the default is Do not allow dynamic updates), and then click Next.

On the Completing the New Zone Wizard page, review the settings, and then click Finish.

Note: If you plan to use apps on an internet-facing website, you have to buy this domain name. Even if you only use it internally, it’s always better to buy it before someone else buys it and registers it in the public DNS.

2. Link the App Domain to the SharePoint Server

We now need to instruct our DNS to forward all the requests from homeapps.com to the SharePoint Server hosting the apps

Verify you are logged in as a Domain Admin
In DNS Manager, under Forward Lookup Zones, right-click the new app domain name, and then click New Alias (CNAME).

In the New Resource Record dialog box, in the Alias name (uses parent domain if left blank) box, type *.

Next to the Fully qualified domain name (FQDN) for target host box, click Browse and navigate to the Forward Lookup Zone for the domain that hosts the SharePoint sites and then navigate to the record that points to the server that hosts the SharePoint site.

Click OK.

Verify the new domain name

This is just a little step to make sure everything we did until now is right.

Click Start, and then click Command Prompt. At the command prompt, type ping followed by a subdomain of the domain that you created, and then press ENTER. (EX: ping test.homeapps.com) where "test" is a random word and homeapps.com is your newly created domain.

If the ping command returns the correct IP address, then your wildcard for the domain name was configured successfully.

3. Start the required services

Apps rely on the App Management and Microsoft SharePoint Foundation Subscription Settings service applications. These service applications use the multi-tenancy features to provide app permissions and create the subdomains for apps. Therefore, even if you are not hosting multiple tenants, you must still establish a name for the default tenant for your environment (any SharePoint site that is not associated with a tenant will be in the default tenant). In this step we will start the two required services!

Verify that you are a member of the farm administrators group in Central Administration.
In SharePoint 2013 Central Administration, click System Settings.
On the System Settings page, under Servers, click Manage services on server.
On the Services on Server page, next to App Management Service, click Start.
On the Services on Server page, next to Microsoft SharePoint Foundation Subscription Settings Service, click Start.

Verify that the App Management and Microsoft SharePoint Foundation Subscription Settings services are running.

4. Create the Subscription Settings and App Management Service Applications

In this step we will create the two Service Applications we talked about in the previous step. As you know, Microsoft is strongly promoting PowerShell to the SharePoint Administrators, and to make sure you start using it, they made it the only way to configure the Subscription Settings Service Application. Since we will be doing PowerShell for the first one, we will both in PowerShell.

Verify that you have the following memberships:

securityadmin fixed server role on the SQL Server instance.
db_owner fixed database role on all databases that are to be updated.
Administrators group on the server on which you are running the Windows PowerShell cmdlets.

i) Create a new App Management Service Application from central admin.

ii) There is no interface provided by SharePoint for creating Subscription Settings service application. Therefore we  will use PowerShell script to create it as follows.

Open SharePoint 2013 Management Shell as an Administrator and run the scripts.
$subscriptionSettingsServiceApplicationName = 'Subscription Settings Service Application'  
$pool = Get-SPServiceApplicationPool 'SharePoint Web Services Default'  
$subscriptionSettingsServiceDB= 'Sharepoint_SiteSubscriptionSettingsServiceDB'  
$subscriptionSettingsServiceApplication = New-SPSubscriptionSettingsServiceApplication -ApplicationPool $pool -Name $subscriptionSettingsServiceApplicationName -DatabaseName $subscriptionSettingsServiceDB   
$subscriptionSettingsServicApplicationProxy = New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $subscriptionSettingsServiceApplication

5. Configure app URLs

In Central Administration, click Apps. On the Apps page, click Configure App URLs.

In the App domain box, type the isolated domain that you created for hosting apps.
In the App prefix box, type a name to use for the URL prefix for apps.

Click OK.

Here is how your URL will look like depending on the settings.

6) Test the App environment
In order to test the environment go to the site and select Add an app link and click on SharePoint Store to view all available apps. The list of all available apps will be displayed as follows:

Click on any of the apps that you wish to add to your site and click on ADD IT button.

The app will display the following popup requesting for permission. Click on Trust it button to grant permission.

In site content page you will that the app has been added to the site.

Click on the app to view further details. You can add the app to any of the pages using an app part about which we will discuss in the upcoming blogs.

Now the environment is completely ready for use and apps can be downloaded and added to the SharePoint site.

Hope you like this post!

SharePoint 2013 - An introduction to SharePoint 2013 App Model

In this post we will discuss about the concept of SharePoint Apps, which is the most newly added aspect in SharePoint 2013. The app programming model helps to create rich apps and publish them in an Office Store or public market place. The app model focuses on the development by customizing and extending the SharePoint sites without full trust access to the target farm.

Why Apps Model?
1) First of all there is no dependency for custom code on SharePoint Server since it executes on Client-Browser or may be in some other scope like IIS or Windows Azure.
2) Apps communicate with SharePoint using Client side object model (CSOM) or Rest Services with OAuth being the authentication mode.
3) Remarkable usability in Tablets and Mobile devices.
4) One step ahead for development in future where cloud hosting could be more preferrable.
5) Moreover, in SharePoint 2013 everything is an app including Lists, Libraries etc.
6) SharePoint apps can be developed with any programming language or technology, provided they are hosted outside the SharePoint (autohosted or provider-hosted model).
7) SharePoint apps can be created using PHP, Java, or any other technology capable of communicating with SharePoint via the new REST API and the OAuth protocol.

Types of Configuration 
1) Full-Page: These apps have an independent UI irrespective of the Sites on which they are hosted. A "Back" button should be provided to navigate back to the parent site which triggered the app.
2) App Parts: App parts renders inside an IFrame from whithin the pages of the parent site. They are also known as Client Parts.
3) UI command extension: These apps are used to extend the UI of the parent site. For example, you can create an app to add a new button to the ribbon.

Types of Hosting
1) SharePoint-hosted: These apps are hosted on the SharePoint Farm within a subweb of the parent site and are capable of using the various SharePoint artifacts such as lists, fields, content types, webparts etc.
2) Auto-hosted: These apps are hosted on Microsoft Windows Azure.They can communicate with SharePoint through events or Client Object Model. "OAuth" is used to enforce secure communication.
3) Provider-hosted: These are very much similar to the Auto-hosted apps, the only difference being that they are deployed on an external hosting enviornment other than SharePoint enviornment and does not necessarily use the Windows Azure environment.

Security Perspective
From a security point of view one can trust SharePoint 2013 app model to be thouroughly secured.
A definite set of permissions are requested by the SharePoint App when it is installed. The app will be installed only if the current user can grant the requested permissions, otherwise the app will not install. Pretty straight formward. Isn't it!!

App Development environment
1) "Napa" office 365 dev tools: This tool is purely client side and ideal for creating SP hosted apps. It doesn't support code behind you can view only markup. Developers can also create apps for Office in a web-based environment hosted in Office 365. Previously code-named “Napa,” this subscription-based online experience is being updating on a weekly basis, according to Microsoft. It consists of a SharePoint site in Office 365 configured for apps and the "Napa" Office 365 Development Tools. You can sign up for the Office 365 Developer Site on the Microsoft web site. The subscription costs $99 per year. But Visual Studio Ultimate and Visual Studio Premium with MSDN subscribers receive a one-year Office 365 Developer Subscription as a benefit, and Office 365 Plan E1 or E3 customers can provision a Developer Site as part of their subscription. A 30-day trial is available.

2) Visual Studio: For developing apps using Microsoft .NET and Microsoft Visual Studio 2012, you will need the Office Developer Tools for Visual Studio 2012, which can be downloaded and installed through the Web Platform Installer 4.0 tool.

You also will need to install the following tools and libraries:
i) SharePoint client components
ii) Windows Identity Foundation SDK
iii) Workflow Tools SDK and Workflow Client SDK
iv) Windows Identity Foundation SDK and Windows Identity Foundation extensions

Note:- If you are working on a server with SharePoint 2013 installed, you need to add only Visual Studio 2012 and the Office Developer Tools for Visual Studio 2012. All the other libraries and tools are already part of the installation set of any SharePoint 2013 environment.

App Deployment
There are three ways that you can access CSOM functionality, so the deployment model that you are using for your SharePoint 2013 app will determine the option that you choose.
1) .NET / Silverlight API
2) JavaScript API
3) REST API

SharePoint 2013 - The content databases, tables and SQL queries

Today we will take a closer look at the content database associated with a SharePoint 2013 Web application and also discuss about some of the important tables, their relationships and some important SQL queries relating them.

The Content Database - Server
Open SQL Server Management Studio and connect to the DB Server configured for SharePoint 2013. You will see a number of databases as shown in the following figure. The databases for SharePoint internal configurations are highlight in red. While other databases are associated with each web application created in SharePoint server including Central Administration Site.

The Content Database - Associated Web application
Lets take an example of the web application named "http://sp2013home:10001/" to understand the content DB structure associated with it.

The Content DB associated with our web application is "WSS_Content_10001". As shown in the following figure a content db consist of numerous tables that are internal managed by SharePoint.

The Content Database - Tables
We will discuss a few important tables that exist in every content database.

1) Sites: Holds information about all the site collections for this content database.

2) Webs: Holds information about all the specific sites (webs) in each site collection.

3) Features: Holds information about all the activated features for each site collection or site.

4) UserInfo: Holds information about all the users for each site collection.

5) Groups: Holds information about all the SharePoint groups in each site collection.

6) Roles: Holds information about all the SharePoint roles (permission levels) for each site.

7) AllLists: Holds information about lists for each site.

8) GroupMembership: Holds information about all the SharePoint group members.

9) AllUserData: Holds information about all the list items for each list.

10) AllDocs: Holds information about all the documents (and all list items) for each document library and list.

11) RoleAssignment: Holds information about all the users or SharePoint groups that are assigned to roles.

12) SchedSubscriptions: Holds information about all the scheduled subscriptions (alerts) for each user.
13) ImmedSubscriptions: Holds information about all the immediate subscriptions (alerts) for each user.


The Content Database - Relationships
Following diagram shows the high level relationship between the tables in the content database.

The Content Database - Important SQL Queries
Following are some of the important sql queries that can be used to view the data in Content DB.

1) Query to get all the top level site collections
SELECT SiteId AS SiteGuid, Id AS WebGuid, FullUrl AS Url, Title, Author, TimeCreated
FROM dbo.Webs
WHERE (ParentWebId IS NULL)

2) Query to get all the child sites in a site collection
SELECT SiteId AS SiteGuid, Id AS WebGuid, FullUrl AS Url, Title, Author, TimeCreated
FROM dbo.Webs
WHERE (NOT (ParentWebId IS NULL))

3) Query to get all the SharePoint groups in a site collection
SELECT dbo.Webs.SiteId, dbo.Webs.Id, dbo.Webs.FullUrl, dbo.Webs.Title, dbo.Groups.ID AS Expr1, 
dbo.Groups.Title AS Expr2, dbo.Groups.Description
FROM dbo.Groups INNER JOIN
dbo.Webs ON dbo.Groups.SiteId = dbo.Webs.SiteId

4) Query to get all the users in a site collection
SELECT dbo.Webs.SiteId, dbo.Webs.Id, dbo.Webs.FullUrl, dbo.Webs.Title, dbo.UserInfo.tp_ID, 
dbo.UserInfo.tp_DomainGroup, dbo.UserInfo.tp_SiteAdmin, dbo.UserInfo.tp_Title, dbo.UserInfo.tp_Email
FROM dbo.UserInfo INNER JOIN
dbo.Webs ON dbo.UserInfo.tp_SiteID = dbo.Webs.SiteId

5) Query to get all the members of the SharePoint Groups
(i) All the members in all the SharePoint Groups in a web application.
SELECT dbo.Groups.ID, dbo.Groups.Title, dbo.UserInfo.tp_Title, dbo.UserInfo.tp_Login
FROM dbo.GroupMembership INNER JOIN
dbo.Groups ON dbo.GroupMembership.SiteId = dbo.Groups.SiteId INNER JOIN
dbo.UserInfo ON dbo.GroupMembership.MemberId = dbo.UserInfo.tp_ID

(ii)All the members in each SharePoint Group in a web application.
SELECT dbo.Groups.ID, dbo.Groups.Title, dbo.UserInfo.tp_Title, dbo.UserInfo.tp_Login
FROM dbo.GroupMembership with (nolock) 
INNER JOIN dbo.Groups with (nolock) 
ON dbo.GroupMembership.GroupId = Groups.ID 
INNER JOIN dbo.UserInfo 
ON dbo.GroupMembership.MemberId = dbo.UserInfo.tp_ID

6) Query to get all the sites where a specific feature is activated
SELECT dbo.Webs.Id AS WebGuid, dbo.Webs.Title AS WebTitle, dbo.Webs.FullUrl AS WebUrl, dbo.Features.FeatureId, 
dbo.Features.TimeActivated
FROM dbo.Features INNER JOIN
dbo.Webs ON dbo.Features.SiteId = dbo.Webs.SiteId AND dbo.Features.WebId = dbo.Webs.Id
WHERE (dbo.Features.FeatureId = '00DGEA71-E2FE-42de-9DF3-A44065BE0104')

7) Query to get all the users assigned to roles
SELECT dbo.Webs.Id, dbo.Webs.Title, dbo.Webs.FullUrl, dbo.Roles.RoleId, dbo.Roles.Title AS RoleTitle, 
dbo.UserInfo.tp_Title, dbo.UserInfo.tp_Login
FROM dbo.RoleAssignment INNER JOIN
dbo.Roles ON dbo.RoleAssignment.SiteId = dbo.Roles.SiteId AND 
dbo.RoleAssignment.RoleId = dbo.Roles.RoleId INNER JOIN
dbo.Webs ON dbo.Roles.SiteId = dbo.Webs.SiteId AND dbo.Roles.WebId = dbo.Webs.Id INNER JOIN
dbo.UserInfo ON dbo.RoleAssignment.PrincipalId = dbo.UserInfo.tp_ID

8) Query to get all the SharePoint groups assigned to roles
SELECT dbo.Webs.Id, dbo.Webs.Title, dbo.Webs.FullUrl, dbo.Roles.RoleId, dbo.Roles.Title AS RoleTitle, 
dbo.Groups.Title AS GroupName
FROM dbo.RoleAssignment INNER JOIN
dbo.Roles ON dbo.RoleAssignment.SiteId = dbo.Roles.SiteId AND 
dbo.RoleAssignment.RoleId = dbo.Roles.RoleId INNER JOIN
dbo.Webs ON dbo.Roles.SiteId = dbo.Webs.SiteId AND dbo.Roles.WebId = dbo.Webs.Id INNER JOIN
dbo.Groups ON dbo.RoleAssignment.SiteId = dbo.Groups.SiteId AND 
dbo.RoleAssignment.PrincipalId = dbo.Groups.ID

Note:- It is highly recommended that you NEVER make any changes through SQL interface because improper use might crash SharePoint Site. 

SharePoint 2013 - Handling page request in IIS

Today, we will discuss about the basic architecture of SharePoint 2013 and its working with IIS.

The SharePoint 2013 Architecture
Unlike Asp.net, a SharePoint website is distributed among 3 logical parts, namely:-
1) IIS - Where website are create for each web application.
2) 15 Hive - Store configuration files, templates and other components for supporting SharePoint 2013.
3) Content Database - Back end server for each web application.

Lets take an example of the Web Application named "http://sp2013home:10001/" to verify these logical sections.

In central admin you can see the web application named "SharePoint : 10001"

Now lets verify this web application on each of the logical sections.

1) The IIS (inetmgr.exe)

Just like a normal asp.net website, virtual directories are created for each web application in sharePoint. This directories consists of the .aspx pages, web.config, short-cuts to 15 hive folders like _layouts, _vti_bin etc. In the following figure you can see a virtual site named "SharePoint : 10001" has been created.

2) The 15 Hive ("C:\Program Files\Common files\Microsoft Shared\Web Server Extensions\15")

All the configuration files like web.config, feature.xml, etc reside in 15 Hive. It also consist of all the in-built SharePoint master-pages, styles, site definitions, etc. Any custom developed component like webparts, user controls, application pages etc is deployed in 15 hive.
The files in hive are accessed by IIS through shortcuts configured by SharePoint inside the virtual directories.
None of the web application related folders are created in 15 hive.

3) The Content Database

This is back-end database base where all the SharePoint data is stored. List Items, Document library contents, site pages etc are stored in the content database. In the following figure you can see a database named "WSS_Content_10001" exclusively created for "SharePoint : 10001" web application.

How does IIS handle a SharePoint request

1) A request for SharePoint page is sent through browser arrives at HTTP.sys in IIS. The HTTP.sys determines if the request is valid. If the request is not valid, it sends a code for an invalid request back to the client.

2) An IIS website monitors for incoming requests through a particular port, and it checks for a particular host header or IP address, or both. Every SharePoint Foundation web application is hosted in an IIS website that has the same name as the web application.

3) The request is passed through a pipeline of units including authenticating the user, verifying the user’s authorization, building the response, sending the response, and finally, logging the request.

4) The response to any request is produced by an HTTP handler object. Requests are assigned to one or another HTTP handler object depending on the resource requested and the HTTP verb in the request.

5) The request pipeline also contains HTTP modules. Modules are assemblies that typically contain one or more event handlers or define new events that other modules can handle. An HTTP module can register for one or more events in the life cycle of the request.

6) The processing of a request by HTTP modules and an HTTP handler is governed by an HttpApplication object or an object derived from that class. SharePoint installs a global.asax file in the root of each web application (IIS website) that identifies SPHttpApplication as the class from which an HTTP application object is created.

7) SharePoint also modifies the pipeline with a custom HTTP module (SPRequestModule), and with changes to the default applicationhost.config file.

8) SPRequest module eventually request the location of the SharePoint configuration database from the registry. Connection string for the SharePoint configuration database is set using DSN key at  HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\Secure\ConfigDB.
So, this is the registry value, you need to change, if you ever need to move configuration database.

9) When an HTTP request is received by a front-end web server, a special driver, HTTP.SYS, detects the request and routes it to the application pool that is handling requests for the targeted IIS website, and thus, the targeted SharePoint web application. Every application pool has an IIS worker process (w3wp.exe) in which the request pipeline for each request is executed.

10) After processing the request, the worker process sends the response back to HTTP.sys which in turn sends the response back to the client and logs the request, if configured to do so.