Productivity solutions

  • 10/9/2017
Contents

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.

Important

The nomenclature for SharePoint (and Office) apps is currently changing; instead of Apps for SharePoint, they are now referred to as SharePoint Add-ins. App Parts and App Webs are also changing nomenclature, named Add-in part and Add-in web, respectively.

Regardless of how they are named, the functionality is the same; as the user interface still refers to these as Apps (Apps for Office, Apps for SharePoint, and so on), we will use the term App when called for in the interface but use the more current designation of Add-in when talking about the individual functionality.

This section covers how to:

  • Configure DNS entries

  • Configure wildcard certificates

  • Create and configure subscriptions

  • Create and configure the App Store

  • Configure marketplace connections

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).

exa.jpg Exam Tip

Although DNS configuration is not necessarily a core skill for effective SharePoint administration, it is nonetheless a good idea to understand how to create the appropriate DNS entries required for your add-in domain.

If at all possible, practice the steps required to both create the forward lookup zone and the CNAME entry by using the DNS console. If this is unavailable, it is strongly suggested that you be familiar with how to start the DNS console and make these entries.

Need More Review?

The steps for creating the forward lookup zone for the app domain as well as those required to create the wildcard entry are shown in the TechNet article entitled “Configure an environment for apps for SharePoint (SharePoint 2013)” at https://technet.microsoft.com/library/fp161236.aspx.

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).

exa.jpg Exam Tip

Be familiar with the process of requesting a new certificate from the IIS console. In particular, remember that this certificate must be installed in IIS for each Front-end server of the farm.

Need More Review?

The processes for both requesting and installing a new wildcard certificate are shown in the TechNet article entitled “Configuring Internet Server Certificates (IIS 7)” at https://technet.microsoft.com/library/cc731977(v=ws.10).aspx.

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.

Important

Although it’s technically possible to create a new App Management service application from Services Applications in Central Administration, Application Management, you might wish to simply go ahead and create this service application from PowerShell. The reason for this is simple: There is no provision for creating the other required service application, the SubscriptionSettingsServiceApplication.

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

FIGURE 4-5 Newly started services in the SharePoint 2016 farm

Need More Review?

The creation of these two service applications is identical to what it was in SharePoint 2013 (except the activating of the supporting services), and is shown in the article “Configure an environment for apps for SharePoint (SharePoint 2013)” on TechNet at https://technet.microsoft.com/library/fp161236.aspx.

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

FIGURE 4-6 Configuring the App URLs

Need More Review?

Configuration of the Add-in URLs is detailed in the TechNet article “Configure an environment for apps for SharePoint (SharePoint 2013)” at https://technet.microsoft.com/library/fp161236.aspx.

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:

  • SharePoint-hosted Used for creating functionality scoped to a single-site collection, created entirely in JavaScript.

  • Provider-hosted Used for more complex business requirements, this functionality can be used to reach across multiple sites and line-of-business apps, and does not necessarily have to be created in JavaScript.

These Add-ins can be developed in house or can be purchased from the Office Store, within the SharePoint Add-Ins section.

Important

The nomenclature can get a bit confusing here; since its inception, the ability to incorporate Add-ins and Apps to SharePoint has been provided both on premises in the App Catalog and Add-in Catalog. The online location for sourcing these Add-ins is currently referred to in Central Administration as simply SharePoint and Office Store; throughout different documentation efforts, you might also hear this location referred to as the SharePoint MarketPlace, App Store, or SharePoint Store.

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.

exa.jpg Exam Tip

An App Catalog site is scoped to a single web application within SharePoint; as a result, farms that maintain multiple web applications can have distinct, matching App Catalog sites.

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.

Important

As we will cover in the section about configuring DNS entries, the site collection that hosts the App Catalog should be set up with its own fully qualified domain name (FQDN); additionally, this FQDN should not be a subdomain (for example, apps.wingtiptoys.com). The reason for using an FQDN is because newly added Add-ins have a unique URL, which is composed of the app domain name plus a prefix and an Apphash (a unique identifier for each app for use with SharePoint). Using a subdomain presents a security risk due to exposing information found in cookies.

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

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.

Application management

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

FIGURE 4-8 Manage Applications page, Web Applications tab, showing the Manage Features and Service Connections icons

Service connections

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

FIGURE 4-9 Ensuring that the App Management Service Application Proxy is selected

Save to your account

This chapter is from the book