- By Troy Lanphier
- Skill: Evaluate content and customizations
- Skill: Plan an upgrade process
- Skill: Create and configure app management
- Skill: Create and configure productivity services
- Skill: Create and configure a Business Connectivity Services (BCS) and Secure Store application
- Skill: Manage SharePoint solutions and applications
- Thought experiment
- Thought experiment answer
Skill: Create and configure app management
In earlier versions of SharePoint, custom code and functionality were created and deployed via full trust solutions in the SharePoint farm. Although this was (and is) a valid way to add new functionality, this mechanism is being superseded by SharePoint apps and add-ins.
One reason for this change is simply that the apps can be created and deployed to both on-premises and cloud solutions. This reusability means that customizations can be developed once and deployed somewhat uniformly to both environments.
Configure DNS entries
To configure Add-ins with SharePoint 2016, you will need to accomplish two tasks in Domain Name Services (DNS): creating a DNS zone for your Add-in domain, and creating a wildcard alias for the new domain name.
Creating a DNS zone for the Add-in domain
By using the DNS console, you will need to create a new DNS zone (such as http://www.wingtiptoysaddins.com). The new DNS zone should be created as a forward lookup zone, and should not be a subdomain of the existing domain that hosts the SharePoint sites (such as http://www.addins.wingtiptoys.com), as this poses a potential security risk (such as cross-site scripting).
This zone is created by using the DNS console on a domain controller, and requires the user creating the zone to be a domain administrator.
Creating a wildcard alias for the domain name
Once the DNS entry for the Add-in domain has been created, the next task is to create a wildcard alias record that points to the SharePoint domain. This record can be created as an Address (A) record, but is more often created as a Canonical Name (CNAME) record.
Using the previous example, you would create a record for *.wingtiptoysaddins.com and point to this by using a CNAME to the SharePoint domain (for example, sharepoint.wingtiptoys.com).
Configure wildcard certificates
It’s technically possible to avoid using Secure Sockets Layer (SSL) with the Add-in functionality in SharePoint, but this is not a recommended configuration, particularly if either of the following is true:
Existing SharePoint sites are using SSL.
Any of the Add-ins to be used connect to data located external to SharePoint sites.
Requesting a wildcard certificate
A new wildcard certificate can be requested from the Internet Information Server (IIS) console and then imported to the SharePoint web application where the App Catalog will be located. When the certificate is imported, it’s important that the Friendly Name entry includes the asterisk character (*), indicating the wildcard (for example, *.wingtiptoys.com).
Create and configure subscriptions
Prior to the creation of the Add-in Catalog, two service applications must be configured in the SharePoint Server 2016 farm:
App Management This service application is responsible for storing and providing SharePoint Add-in licenses and permissions, including those downloaded from the SharePoint and Office Store.
Subscription Settings This service application enables the sharing of stored setting data within a set of site collections.
Creating these two new service applications is a bit different in a MinRole-compliant SharePoint 2016 environment than it was in SharePoint 2013. Particularly, the supporting services for each service application (App Management Service and Microsoft SharePoint Foundation Subscription Settings Service) are automatically provisioned and started in servers holding the Front-end and Application roles within the SharePoint 2016 farm (Figure 4-5). No manual start and stop is required.
FIGURE 4-5 Newly started services in the SharePoint 2016 farm
Configuring the Add-in URLs for use
The last step in the subscription process is to create the App domain prefix and the tenant name to use for Apps in this SharePoint environment. Within the Apps section of Central Administration, select Configure App URLs (under App Management, shown in Figure 4-6).
FIGURE 4-6 Configuring the App URLs
Create and configure the App Store
Apps for SharePoint (now called SharePoint Add-ins) are self-contained extensions of SharePoint websites (on premises or online) that are created without the need for custom code on the SharePoint server farm. Two types of these Add-ins exist:
These Add-ins can be developed in house or can be purchased from the Office Store, within the SharePoint Add-Ins section.
SharePoint Add-ins and the App Catalog
Before SharePoint Add-ins can be installed to a SharePoint farm, an App Catalog must be configured for use. This catalog hosts both locally created Add-ins as well as those hosted within SharePoint and Office Store (also known as the App Store).
Apps in the catalog site are stored in one of two document libraries: Apps for SharePoint or Apps for Office. As the administrator, you can choose which of these libraries can be utilized by your user base.
A new App Catalog can be created simply by selecting the Apps within Central Administration and then selecting Manage App Catalog. Once there, you can choose to either create a new App Catalog site (no different than creating a standard SharePoint site) or enter a URL for an existing App Catalog site.
Configure marketplace connections
Connections to the SharePoint Marketplace (now known as the Office and SharePoint Store) are configured in two distinct locations within Central Administration: SharePoint Store Settings and Application Management.
SharePoint Store Settings
The first configuration that is required is to decide on a per-web-app basis whether users will be able to select SharePoint Apps, Office Apps, both, or neither for use within the SharePoint farm.
This selection is made within the SharePoint Store Settings page of the Apps section in Central Administration, and is configured on a per-web-app basis (shown in Figure 4-7).
FIGURE 4-7 SharePoint Store Settings page
Selecting the appropriate web application then allows the admin to choose from three settings:
App Purchases Choose whether users should be able to get apps from the SharePoint Store.
App Requests View any pending app requests.
Apps For Office From The Store Allow Apps for Office to start when users interact with documents in a web browser.
If sites in a web app are configured to allow Internet-facing endpoints, you can turn on the Internet-facing endpoints feature to allow the use of Add-ins that support this functionality; otherwise, these Add-ins are unavailable in the SharePoint Store.
Selecting the web app and then selecting Manage Features (Figure 4-8) allows you to activate the feature called Apps That Require Accessible Internet Facing Endpoints. This can be useful when your users are unable to access the SharePoint Store with the message Sorry, We Can’t Seem To Connect To The SharePoint Store.
FIGURE 4-8 Manage Applications page, Web Applications tab, showing the Manage Features and Service Connections icons
Depending on how your environment was configured, you might have more than a single App Management service application. If this is the case, you might need to choose the service application connections used for your web application; in our case, we are concerned that we select the correct connection group and then select the App Management Service Application Proxy (see Figure 4-9).
FIGURE 4-9 Ensuring that the App Management Service Application Proxy is selected