Productivity solutions

Skill: Manage SharePoint solutions and applications

From an extensibility standpoint, SharePoint has several options, depending on whether development efforts are specific to an on-premises deployment or meant for working in a hybrid situation. This skill begins with solutions (both sandboxed and full trust), then moves into the Add-in (previously referred to as App) model functionality.

Manage sandbox solution quotas

Sandbox solutions are code that runs in a very restricted execution environment. Maintaining these solutions in this space limits the amount of resources they consume from the SharePoint farm as a whole, perhaps preventing a poorly written solution from potentially taking down the entire SharePoint farm.

Sandbox solutions are monitored by SharePoint for resource usage on a per-site-collection basis, and assigned points (via quota) that can be used on a daily basis. If this limit is reached, all sandboxed solutions within the site collection are disabled for the rest of the day, then reset by the Solution Daily Resource Usage Update timer job.

Creating a new quota template

A quota template provides a reusable mechanism for quickly assigning storage and resource limits to a series of site collections. Quota templates are assigned in Application Management, Site Collections, Specify Quota Templates, and require that the following fields be completed:

• Template Name Choose to either edit an existing quota template or create a new one.

• Storage Limit Values Limit site storage and set a warning threshold for an email notification in the site collection.

• Sandboxed Solutions With Code Limits Limit the maximum resource usage per day (default is 100 points), also setting a warning threshold for an email notification in the site collection.

Altering a site collection quota

It might be the case that a particular site collection needs a temporary change in resources or perhaps will be receiving a custom site collection quota, assigned without the use of a quota template. These quotas are assigned in Application Management, Site Collections, Site Collection Quotas and Locks, and require the following fields be completed:

• Site Collection The site collection selected is the one for which the quota is being changed or unlocked.

• Site Lock Information This indicates the existing website collection owner as well as the current lock status for the site (which can be altered): Not Locked, Adding Content Prevented, Read Only, or No Access.

• Site Quota Information Allows for the selection of a predefined quota or the assignment of limits for both storage and resource quotas.

Configure sandbox solution management

Sandbox solution management can be found in Farm Management, under Manage User Solutions. This page allows the administrator to accomplish one of two distinct tasks:

• Solution Restrictions Within this section, an administrator can do the following:

  • Name a solution that should be blocked and prevent it from running.

  • Optionally, display a message to the user, describing why this particular solution is disallowed in the farm.

• Load Balancing This section has to do with performance and the load on a particular server.

  • Choosing to run all sandboxed code on the same machine as a request might perform better for smaller deployments, but not be able to handle a larger number of simultaneous requests.

  • Choose instead to use solution affinity to balance requests across multiple servers running the Microsoft SharePoint Foundation Sandboxed Code service.

Deploy farm solutions

Farm solutions are a type of on-premises code deployment wherein dynamic-link libraries (DLLs) can be added to the global assembly cache. This type of deployment means that the solutions are “trusted,” and therefore not subject to the same limitations placed on User (sandbox) solutions.

Although full trust solutions cannot be used in SharePoint Online, they are still a viable mechanism for deploying new functionality within an on-premises or cloud-hosted SharePoint farm, such as that found in Microsoft Azure. Before a solution package can be deployed in a SharePoint farm, it has to be submitted to the Solution Store in the configuration database by way of the Add-SPSolution cmdlet.

Adding and installing solutions

The process of deploying a farm solution is fairly straightforward:

1. Add the farm solution Before the solution can be deployed, it has to be added to the farm by using the Add-SPSolution cmdlet (there is no provision for adding a farm solution via Central Administration).

2. Deploy the farm solution Once the solution has been added, it can be deployed:

   • Via PowerShell by using the Install-SPSolution cmdlet

   • Via Farm Management, Manage Farm Solutions in Central Administration

Backward compatibility

As you are busily creating a new SharePoint 2016 environment, you might actually be ahead of the development curve. The full trust solutions you’ve maintained until now might be built for SharePoint 2013 (or even SharePoint 2010).

Fortunately, SharePoint has mechanisms in place that allow you to continue using older solutions, in the form of the -CompatibilityLevel switch, used with the Install-SPSolution cmdlet. On a SharePoint 2016 farm server, three folders exist at C:\Program Files\Common Files\Microsoft shared\Web Server Extensions (Figure 4-21), representing three different modes:

• 14 folder Installing a solution into the 14 folder indicates SharePoint 2010 compatibility mode.

• 15 folder Installing a solution into the 15 folder indicates SharePoint 2013 compatibility mode.

• 16 folder Installing a solution into the 16 folder indicates SharePoint 2016 compatibility mode.

FIGURE 4-21 The Web Server Extensions folder, with the 14, 15, and 16 folders

Upgrade farm solutions

After you’ve completed your SharePoint 2016 deployment and upgrade, your development teams or vendors might produce newer versions of the solutions present in your farm. When this occurs, you will need to work with these groups to better understand the changes made to the solution, as the act of upgrading a solution has two distinct flavors:

• Updating a SharePoint solution When the version of a SharePoint solution has been updated, the existing solution can be upgraded in place, if and only if the files and features are exactly the same as in the previous version. This replacement is done by using the Update-SPSolution cmdlet.

• Replacing a SharePoint farm solution More often than not, an updated solution means that new components, functionality, and (perhaps) bug fixes are also rolled in for good measure. This type of an update requires that the existing solution be retracted (Uninstall-SPSolution) and redeployed (Install-SPSolution).

Deploy Apps

Site Owners in a SharePoint farm have the ability to provide Add-ins in their sites from one of three locations:

• From a list of Add-ins that were already available for a site

• From the privately available App (Add-in) Catalog

• From the commercial Office Store

In particular, this section isn’t about commercially available Add-ins from the SharePoint Store; it concentrates instead on in-house development and deployment of Add-ins. SharePoint Add-ins that are developed in house often provide a level of customization over and above what can be purchased in the store, but they must be maintained just like the older, full trust solutions. These Add-ins can be added to the organization’s private Add-in Catalog.

Installing an Add-in via the Add-in Catalog

Importing and installing an Add-in is as simple as uploading a document. Open the Add-in Catalog site for the particular web application, and then select the Apps for SharePoint library.

Within the library, the new Add-in can be uploaded. At this point, the Item Details box will appear, prompting for the Name, Title, Short Description, Icon URL, and other settings.

Importing and installing an Add-in via PowerShell

Prior to the installation of an Add-in, the installer must be a member of certain roles and groups:

• Securityadmin fixed role on the SQL server instance

• Db_owner fixed database role on all databases that are to be updated

• Administrators group on the local server where PowerShell cmdlets are to be run

• Site Owners group on the site collection to which you want to install the Add-in

The process of deploying an App or Add-in in a farm via PowerShell is similar to deploying a solution:

• Import the Add-in package Before the Add-in can be installed, it has to be added to the farm by using the Import-SPAppPackage cmdlet (there is no provision for adding an Add-in via Central Administration).

• Deploy the Add-in Once the Add-in has been added, it can be deployed; in the case of Add-ins, there is no provision for installing them via Central Administration. Install the Add-in via PowerShell by using the Install-SPApp cmdlet.

Upgrade Apps

After an Add-in has been installed, development might begin on a newer version of the Add-in. At some point, you might wish to place this new Add-in within the Add-in Catalog. When this occurs, you will need to decide which of the following two mechanisms you will use:

• Updating a SharePoint Add-in When the version of a SharePoint solution has been updated, the existing solution can be upgraded in place if (and only if) the files and features are exactly the same as in the previous version. This replacement is done by using the Update-SPAppInstance cmdlet.

• Migrating from an older Add-in to a newer Add-in Depending on the need, you might decide to develop a new Add-in that replaces, rather than upgrades, the original Add-in. If this is the case, you will need to use the same friendly name and file name of the package, but have a different product ID in the manifest. This will allow the Add-in to effectively replace the original in the catalog.