With the recent Release to Manufacturing (RTM) of SharePoint 2013, I figured it was time to see what the new app development model is all about.
Spinning up the farm
The environment contains three machines:
- SharePoint Server 2013 RTM (Windows Server 2012, 80 GB disk, 5 GB RAM) – also has Visual Studio 2012 Professional, and Office Professional Plus 2013 installed…in other words, everything you need to get started developing apps and solutions for Office 2013 and SharePoint 2013!
- SQL Server 2012 SP1 (Windows Server 2012, 40 GB disk, 2 GB RAM)
- Windows Server 2012 domain controller (40 GB disk, 1 GB RAM)
My farm was provisioned and ready to go in less than 8 minutes! That’s countless hours of installation and configuration time saved, allowing me to get right down to business. Let’s start with a brief overview of the SharePoint 2013 app development model.
The SharePoint 2013 app development model
In SharePoint 2010, developers had two options for deploying custom functionality:
- Farm solutions allow access to the full SharePoint server-side API and run in the context of the SharePoint server process. They have a significant footprint on the SharePoint server and are capable of causing farm-level outages if errors or other issues occur.
- Sandboxed solutions allow access to a limited subset of the SharePoint server-side API and can be deployed and managed by site collection administrators. They run in a separate memory process on the SharePoint server, confining problems to the site collection level if errors or other issues occur.
Because of the nature of farm solutions, they required an on-premises deployment of SharePoint. Hosted and multi-tenant installations of SharePoint could take advantage of sandboxed solutions, but many developers viewed them as significantly limiting in terms of the capabilities they could offer. In fact, developing new sandboxed solutions is deprecated in SharePoint 2013 (although existing sandboxed solutions are still supported).
Enter apps for SharePoint!
While farm solutions remain the mechanism of choice to deploy deep customizations to the platform, apps for SharePoint were introduced in SharePoint 2013 to maximize the level of capability and flexibility which allow developers to deliver without risking compromise to the farm. In an app, no server-side code runs on the same server as SharePoint. This protects the farm while still enabling developers to extend the capabilities of a SharePoint site. Apps for SharePoint come in three flavors: (I believe this to be whimsical, but if not, change to ‘variations’)
- SharePoint-hosted apps are deployed to a SharePoint 2013 site (an SPWeb known as the host web) and provision their resources on a subsite (an SPWeb known as the app web). These are the mechanism of choice for simple solutions that interact with SharePoint lists and libraries and require the use of client-side technologies (such as the REST-based APIs and/or the Client Script Object Model) to interact with the SharePoint server.
- Provider-hosted apps are deployed outside the SharePoint server and can run in the cloud or on a separate web server (running IIS or any other platform).
- Autohosted apps automatically provision web sites and databases to Windows Azure and SQL Azure in a way that is transparent to the end user, allowing for ultimate scalability and flexibility.
Configuring the environment to support apps for SharePoint
Naturally, as a developer, the first thing I did after provisioning my environment was to crack open Visual Studio and try to deploy a simple “Hello World” app. (Disclaimer: I first had to download and install the Microsoft Office Developer Tools for Visual Studio 2012 RTM, available here.)
Unfortunately, this resulted in an error:
(Hey, I had to try!)
Examining the ULS logs revealed the following:
SPException thrown: Message: Apps cannot be installed. Review the diagnostic logs for more details regarding app deployment failures.
As it turns out, before you can begin to develop and deploy apps for SharePoint in the SharePoint 2013 RTM Small Farm environment, some additional configuration is necessary. As I go through these steps, I will be logged in to the SharePoint server with an account in the farm administrators group. I will also be logged in to the domain controller with a local administrator account on that machine.
Set up the app domain in DNS
To help ensure security within apps for SharePoint, a separate DNS domain name is required for all installed apps. This domain should NOT be a subdomain of the domain on which SharePoint is hosted. This process of app isolation ensures separation between the app and SharePoint sites to prevent unauthorized access to user data as well as guard against cross-site scripting (XSS) attacks.
In the CloudShare SharePoint 2013 RTM Small Farm, a SharePoint web application is configured at http://sp2013srv. I will set up DNS to support apps for SharePoint running on the domain sp2013apps.com. Every time an app is provisioned, a unique DNS name will be created (such as apps-12345678ABCDEF.sp2013apps.com, where 12345678ABCDEF is a unique 14-character identifier for the app and apps is a special prefix I define). The configuration steps below will allow us to resolve these domain names.
On the Windows Server 2012 x64 W/ Active Directory server (our domain controller), we launch DNS from the Windows Server 2012 Start screen.
Right-click Forward Lookup Zones and select New Zone…
On the opening screen of the wizard, click Next.
Choose Primary Zone, select Store the zone in Active Directory and click Next.
Choose to replicate the DNS data To all DNS servers running on domain controllers in this domain and click Next.
Enter the name of the new zone (in our case, sp2013apps.com) and click Next.
Select Allow only secure dynamic updates and click Next.
Now we will create a wildcard Alias (CNAME) record to allow apps to create unique domain names within our app domain, sp2013apps.com. Right-click sp2013apps.com and select Refresh. Then right-click sp2013apps.com and select New Alias (CNAME)…
In the Alias name field, enter * to allow for unique aliases to be created as apps for SharePoint are provisioned. Enter sp2013srv.ad2012.loc (the FQDN of the SharePoint server) and click OK.
We can verify our DNS setup by pinging a random unique domain name on our app domain. Open a command prompt and enter ping apps-12345678abcdef.sp2013apps.com. If the domain resolves, everything is set up properly.
Note that in a production environment, you would want to use SSL for your apps for SharePoint. In that case, you would also need to obtain and configure a wildcard SSL certificate for your app domain.
Configure the Subscription Settings service application
NOTE: Before proceeding, we need to reset the credentials for the AD2012\Administrator managed account within SharePoint (whose password presumably gets changed during the environment provisioning process). SharePoint needs to know about this password change (when it is changed outside of SharePoint) in order for services that rely on this managed account to work properly. To do this, run the following command from a SharePoint 2013 Management Shell (running as Administrator):
Set-SPManagedAccount -UseExistingPassword -Identity AD2012\Administrator
When prompted, enter the value for ExistingPassword (which can be obtained from the machines list on the environment’s home page).
Now run the following command to ensure no errors are returned:
Finally, perform an IISRESET.
Apps for SharePoint require proper configuration of the App Management and Microsoft SharePoint Foundation Subscription Settings service applications. In the CloudShare SharePoint 2013 RTM Small Farm, the App Management Service Application is already configured but the Microsoft SharePoint Foundation Subscription Settings Service Application is not. We create a new Subscription Settings service application (with its own application pool) and proxy using PowerShell by entering the following commands from a SharePoint 2013 Management Shell (running as Administrator):
$account = Get-SPManagedAccount AD2012\administrator
$appPoolSubSvc = New-SPServiceApplicationPool -Name SettingsServiceAppPool -Account $account
$appSubSvc = New-SPSubscriptionSettingsServiceApplication -ApplicationPool $appPoolSubSvc -Name SettingsServiceApp -DatabaseName SettingsServiceDB
$proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $appSubSvc
To verify that the SettingsServiceApp was created, go to Manage service applications under Service Applications in Central Administration. The following should now appear:
Configure app URLs
Finally we must define the app prefix for apps to use in our environment. For instance, the app URL apps-12345678abcdef.sp2013apps.com has a prefix of apps. We will configure our environment to use this prefix.
From Central Administration, go to Apps.
Select Configure App URLs.
Specify an App domain of sp2013apps.com and an App prefix of apps, then click OK.
Congratulations! You are now ready to take advantage of apps for SharePoint! My simple HelloWorld app now deploys from Visual Studio without any errors:
After completing these configuration steps, the CloudShare SharePoint 2013 RTM Small Farm is now ready to support the development, installation, and deployment of Apps for SharePoint!
If you found this article useful you might also be interested in:
SharePoint compatibility level – How to Change SharePoint Compatibility Range at the Web Application Level