The App Store allows users—either all or a subset—to acquire apps easily. This isn’t something that happens automatically, which is good because otherwise users could put apps on your farm that you as a farm administrator would know nothing about. You need to configure the store based on your organization’s needs, but before you can start the configuration process, you need to perform some steps.

First, you need to create at least one App Catalog site collection. Each web application can have its own App Catalog, so you can have as many as you have web applications; however, you need only one to start with. The App Catalog site has two special libraries that exist in the site—Apps for SharePoint and Apps for Office—so that the App Catalog can supply apps to both SharePoint and Office. The App Catalog can be created by a member of the Farm Administrator group by following these steps (assume that the App Management Service has been started):

As soon as an App Catalog site collection exists, you can specify the store settings for the web application on which the App Catalog exists. These settings determine how users will interact with the store and give you a place to view app requests. Following these steps to configure these settings:

The App Requests list in the App Catalog site collection can be accessed at the site or from Central Administration. It lists requests that users have put in because they want to install apps from the SharePoint Store. Users can request a single or multiple licenses as well as provide reasons for the app request. The relevant fields in the list and descriptions are as follows:

Administrators (members of the Owners or Designers groups) of the App Catalog site collection can also manually add apps to the catalog, making them available to all users who have permissions to the App Catalog. Follow these steps to add apps to the App Catalog:

You should have an App Catalog at this point, but you still might not be able to add apps from the SharePoint Store. You can go out to the SharePoint Store and look at the apps that are available but can’t add them to the catalog. Some steps and configurations still need to be verified, as described in the following sections.

Apps rely on two services to run: the App Management service and the SharePoint Foundation Subscription Setting service. If you have an App Catalog site created, the App Management service should be running, but the SharePoint Foundation Subscription Setting service is off by default. You can turn it on by following these steps:

Because the Microsoft SharePoint Foundation Subscription Settings Service uses the multi-tenancy feature, even if you aren’t providing hosting, you still need to provide a default tenant. You do so by establishing a name for the default tenant, and then any SharePoint site not specifically associated with another tenant will be part of the default tenant.

Setting up the Subscription Services service application needs to be done with PowerShell commands. This is a little more complicated than setting up a typical service application, so the details of how to go about this are as follows:

After you configure the Subscription Settings service, you can configure the app URLs. If you try to do this beforehand, you will get an error when you go to the Configure App URLs page. The two settings to configure on this page are App Domain and App Prefix. Specifying an app domain on this page defines a default tenant name. If you are hosting SharePoint instances and require multi-tenancy, you must use PowerShell to configure the app domains and the app prefixes. The app prefix is prepended to the subdomain of the app URLs. If you have a single tenant, you can use Central Administration to configure the app URLs:

Figure 4-1 shows the configured settings, using contoso.com as the app domain and App as the app prefix.

Figure 4-1. Configure App URLs page

At this time, you (and users with permissions to add Apps) should be able to go out to the SharePoint Store and start adding apps to the App Catalog. When you first set this up, you should go out to the SharePoint Store yourself and see the host of available apps. It also gives you a sense of who in your organization should have access to the SharePoint Store.

For security reasons, t is recommended that you use a different domain name for hosting apps from the domain name for the SharePoint farm or subdomain of the farm. This means that you need to configure a new name in Domain Name Services (DNS) before you start creating the App Catalog and configuring the service applications App Management and Microsoft SharePoint Foundation Subscription Settings. For the purposes of the exam, assume that you’ve purchased your domain name from a domain name provider.

Configuring DNS is done differently, depending on the operating system that your DNS server uses. For this objective, you need to be concerned only with Microsoft products. Assuming that you are using Microsoft Windows Server, you should configure a forward lookup zone with the domain name (if you are using Windows Internet Name Service (WINS) forward lookup). To configure a forward lookup zone on a Windows Server instance, follow these steps:

When an app is added to the App Catalog, it receives a unique new domain name. For example, if the app prefix is App and the app domain name is contoso.com, an added app might be accessed by http://app-123ABC.contoso.com, where 123ABC is the application ID. To support these unique domain names, a wildcard Canonical Name (CNAME) entry for the DNS entry needs to be created. Like the forward lookup zone, this is done on the domain controller. To create a CNAME record on a Windows Server instance, follow these steps:

After you configure the CNAME record, you can access the unique domain names that the app service creates whenever an app is added. If you’ve decided to use Secure Socket Layers (SSL), you still need to configure a wildcard certificate, as explained in the next section.

Each app that exists in the App Catalog has a unique name, which can present some problems when using Secure Socket Layers (SSL). Each unique domain name that uses SSL requires a certificate, but you don’t want to go around creating and installing certificates every time somebody puts an app in the App Catalog. To get around this, you need to obtain and install a wildcard certificate. To obtain a wildcard certificate, you can request one from your SSL certificate provider. To create a request for a wildcard certificate, follow these steps:

When you have the SSL certificate in hand, you need to import it into IIS on each WFE. After the certificate is imported, it needs to be bound to the website where the App Catalog resides. To import an SSL certificate, follow these steps:

After the SSL certificate is installed on the WFE, you can bind the certificate to the web application where the App Catalog resides. This is also done in IIS by following these steps:

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

One of the most useful and powerful service applications available to SharePoint, the Microsoft Excel Services service application enables users to use Excel spreadsheets right within the browser and provides all document management benefits (versioning, security, collaboration, check in/out, and so forth) that other kinds of documents have within SharePoint. Excel Services also allows for the showing of just part of the Excel spreadsheet and the ability to display graphs and charts to users who don’t have access to the spreadsheet.

Before users can start using Excel Services, you must create the service application. And before you can create the service application, you need to make sure that the following items are set up:

Access to the content databases that need Excel Services can be done at the web application level by using PowerShell, as follows:

$webApp=Get-SPWebApplication -identity <URL of web application>
$webApp.GrantAccessToProcessIdentity("<domain account>")

After the account has the proper permissions, you can begin the process of setting up Microsoft Excel Services. For the Excel Services application to be created, you need to start the Excel Calculation Services (ECS) service on at least one server (or on additional servers to provide additional resources, depending on the servers available and the resource demand expected). To start ECS, follow these steps:

After the ECS service starts, you can create the Excel Services application. You need only one application per SharePoint farm. Follow these steps:

After you create the Excel Services application, you need to configure it. In fact, the Excel Services application has more options to configure than any other service application that comes with SharePoint 2013. Figure 4-3 shows the vast array of configurable options associated with this service.

Figure 4-3. The Manage Excel Services Application settings page

Defining trusted file locations

Trusted File Locations productivity services is the second settings group on the Manage Excel Services Application settings page. This group defines the locations that SharePoint can use to open an Excel workbook.

By default, Excel Services is configured to allow workbooks (or parts of workbooks) to be opened within the SharePoint environment under http://. These default settings are designed to provide the Excel Services to the broadest set of users, but they can also present some security risks. Many different Trusted File Locations can enable a high degree of control over where and how Excel Services can use Excel files. The reasons for configuring these settings are for performance and security. In the Trusted File Locations section, you can edit existing file locations or you can add a new one. For the purposes of this section, either is a valid choice for viewing the available options.

Exam Tip

Creating a trusted file location is a prime target for questions that involve steps. It’s also one of the main tasks involved with setting up a SharePoint farm. You should familiarize yourself with creating a few before the exam.

Location settings

The first section, Location, is where you view or add a trusted file location:

• Address. Enter the location, which can be a SharePoint location, a network file share, or a web folder.

• Location Type. Choose the storage type: SharePoint, UNC, or HTTP UNC is for file shares, and HTTP is for locations accessed via the HTTP protocol.

• Trust Children. If the check box is selected, all sublocations are also trusted. For example, if you want to trust an entire web application, you can put the top-level location in the Address field and then select Children Trusted.

• Description. Use normal text to describe the location’s purpose.

Figure 4-4 shows an example of using the http://contoso web application and all subsites and libraries.

Figure 4-4. The Location section for the http://contoso trusted file location

Session management settings

The next section on the Trusted File Location page is Session Management. Because each open session consumes memory resources, managing these options can help keep memory requests under control. If you are experiencing a heavy load on your servers running ECS, you probably want to determine if these properties need to be modified to provide a more responsive SharePoint experience:

• Session Timeout. The amount of time, in seconds, that an ECS session remains open and inactive before it’s shut down. The default is 450 (7.5 minutes). A value of –1 can be specified for no timeout, and the max is 2073600 seconds (24 days).

• Short Session Timeout. The amount of time, in seconds, that an Excel session can remain open and inactive. The default values and limits are the same as for Session Timeout. The Short Session Timeout is measured from the end of the initial open request.

• New Workbook Session Timeout. The maximum amount of time, in seconds, that an ECS session for a new workbook can remain open and inactive before it’s shut down. The default value is 1800 (30 minutes). The maximum is 24 days, and a value of –1 indicates no timeout.

• Maximum Request Duration. The maximum amount of time in seconds for a single request during an ECS session. Default is 300 (5 minutes). The maximum is 24 days, and a value of –1 indicates no timeout.

• Maximum Chart Render Duration. The maximum amount of time in seconds to spend rendering any single chart. The default is 3 seconds. The maximum is 24 days, and a value of –1 indicates no timeout.

Workbook settings

The Workbook Properties section deals with the maximum size of the workbook as well as the objects contained within. Two settings are available:

• Maximum Workbook Size specifies the maximum size, in megabytes, of a workbook that can be opened by ECS. The default value is 10 MB, which should be large enough for most workbooks unless they have a lot of graphics in them. The valid values are 1 through 2000.

• Maximum Chart Or Image Size pertains to the maximum chart size or image size that can be opened by ECS. The default is 1 MB and the maximum is any positive integer (the maximum workbook size is still the limiting factor because the workbook must be open before a chart or image contained within can be opened).

Important

Use caution when raising the values of the workbook properties. Opening up an extremely large workbook can cause the entire SharePoint farm to slow down, especially the server that provides the ECS session.

Settings for calculation behavior

Next, you consider the Calculation Behavior settings:

• Volatile Function Cache Lifetime specifies the amount of time, in seconds, that a volatile function is cached for automatic recalculations. The default value is 300 (five minutes). The value of –1 indicates that it’s calculated once on load. The value of 0 means that it’s always calculated, and the maximum value is 2073600 (24 days).

• Workbook Calculation Mode specifies a workbook’s calculation mode. The default selection is File, which doesn’t override the workbook settings (unlike all the other options). This means that whatever the workbook specifies is what is used. The next option is Manual which means that the end user needs to specify that the calculations in the workbook need to be processed. The value of Automatic means that when data is changed within the workbook then all relevant cells that use that data as part of a calculation are updated. The final selection of Automatic except data tables means that the user has to request that calculations be updated for data that is from external data sources. Choosing either one of the Automatic options puts additional strain on the ECS but also provides the most up-to-date data.

External data settings

External data sources can consume memory and CPU resources as well as be a source of security risk. The settings for this section depend heavily on how your organization treats data and the reliability of the data sources that the Excel workbooks consume:

• Allow External Data determines whether you should even allow external data sources. You can choose from the following values:

  • None prevents users from accessing external data sources.

  • Trusted Data Connection Libraries allows only connections available within SharePoint data connection libraries. This option allows for access to external data but provides a mechanism to control the data connections and the accounts used to access the external data.

  • Trusted Data Connection Libraries And Embedded is the most open and doesn’t allow for oversight of data connections. This option should be allowed only in organizations where the data connections are trusted.

• Warn Of Refresh displays a warning before a user refreshes data from an external data source.

• Display Granular External Data Errors displays granular error messages (rather than a general error message) from external data failures. This option is selected by default.

• Stop When Refresh On Open Fails stops the open operation if the file contains a Refresh On Open operation that fails. This option is selected by default.

• External Data Cache Lifetime contains two fields: one for automatic refresh and one for manual refresh. The values determine the maximum amount of time that the system can use external data query results. The default is 300 for both (5 minutes). A value of –1 means never refresh after the first query, and the maximum amount of time is 24 days.

• Maximum Concurrent Queries Per Session determines the maximum number of external data queries per ECS session. The default is 5.

• Allow External Data Using REST allows requests from REST APIs to refresh external data connections. This option is disabled by default.

Settings for user-defined functions

The default setting for the User Defined Functions section is cleared. You should allow user-defined functions only if you fully trust the users creating the functions. You should probably enable this setting only in specific cases—for example, where the library that contains the Excel workbook has very limited access such as for the Finance team. Allowing user-defined functions is a very big security risk and should be allowed only in organizations that fully trust all their members.

Microsoft Access has been increasingly integrated into SharePoint over the last few releases, and SharePoint 2013 is no exception. Microsoft Access Services in SharePoint 2013 allows users to do the following:

New in SharePoint 2013 are Access apps, which are a new type of database built into Access Services that can be shared with other users as an app within SharePoint. This provides Access functionality within the browser. SharePoint 2013 also maintains backward compatibility with Access web databases that were previously created in SharePoint 2010. These two functions each have their own service and their own service application, and they are configured separately.

Access Services

Access Services is the service application in SharePoint 2013 that allows you to create Access apps that can be used and shared across the SharePoint farm. You can then create the Access apps in much the same way you would a document library or list. If you don’t have any legacy Access 2010 web databases, this will be the only Access Services service application that you need to provide database functionality.

Before you start using Access Services, be aware that the requirements for Access Services exceed those of the base installation of SharePoint Server 2013. The following items are required before users can start using Access Services:

• A SQL Server 2012 instance needs to be configured for Access Services.

• The SQL Server Feature Pack needs to be installed on SharePoint.

• The Access Services service application needs to be installed and configured.

• A SharePoint site collection for Access apps needs to be created.

• Creators of Access apps need the Microsoft Access 2013 client to design Access apps.

Exam Tip

That Access Services requires the use of SQL Server 2012 might come up on the exam because this is beyond the usual requirements for SharePoint Server 2013.

Making SQL Server 2012 available

The first step in getting ready to use Access Services is to make sure that SQL Server 2012 is available. If your SharePoint 2013 farm is installed on SQL Server 2008 R2 and you can’t upgrade it to SQL Server 2012, you can still use an instance of SQL Server 2012 to run Access Services and attach it as a separate application database server. Assuming that you have a SQL Server 2012 instance available, you configure it for Access Services.

The account that runs Access Services must have certain built-in server roles on the SQL Server instance:

• dbcreator

• securityadmin

SQL Server 2012 must also have certain components installed before it can be used by Access Services. You might already have these services installed on SQL Server, but you still want to double-check to make sure. The required components—in addition to the database engine and SQL Server Management Studio—are as follows:

• Full-Text and Semantic Extractions for Search

• Client Tools Connectivity

The next step in configuring SQL Server 2012 is to ensure that the following properties and settings are configured:

• Mixed Mode Authentication. In SQL Server Management Studio (SMSS), you can configure this setting through the server’s properties in the Security section.

• Enable Contained Database. In SMSS, you can configure this setting through the server’s properties in the Advanced section. Under the Containment heading, set Enable Contained Databases to True.

• Allow Triggers To Fire Others. In SMSS, you can configure this setting through the server’s properties in the Advanced section. Under the Miscellaneous heading, set Allow Triggers To Fire Others to True.

• Named Pipes. This needs to be enabled through the SQL Server Configuration Manager. Under SQL Server Network Configuration, select Protocols For MSSQLSERVER and set Named Pipes to Enabled. This change requires a restart of MSSQLSERVER.

• Firewall settings. You need to open TCP 1433, TCP 1434, and UDP in the Windows Firewall (or other firewall product) if they haven’t already been opened.

When the components are available and the settings are configured correctly, SQL Server 2012 should be ready for Access Services. Each Access app creates its own database, so you should keep an eye on the number of databases and the memory that they are using.

SharePoint 2013 servers running Access Services also need SQL Server components installed on them. The necessary components can be found in the Microsoft SQL Server 2012 Feature Pack:

• Microsoft SQL Server 2012 Local DB

• Microsoft SQL Server 2012 Data-Tier Application Framework

• Microsoft SQL Server 2012 Native Client

• Microsoft SQL Server 2012 Transact-SQL ScriptDom

• Microsoft System CLR Types for Microsoft SQL Server 2012

More Info: Downloading the Microsoft SQL Server 2012 Feature Pack

You can download the Microsoft SQL Server 2012 Feature Pack at http://www.microsoft.com/en-us/download/details.aspx?id=29065.

Starting the Access Services service

The next step (although this step could have been done earlier as well) is to start the Access Services service. Follow these steps:

1. Navigate to Central Administration with a farm administrator account and click Manage Services On Server in the System Settings section.

2. Choose the server on which you want the Access Services service running by choosing it from the drop-down list next to the word Server.

3. Click Start under the Action column on the line that has Access Services under the Service Column.

4. Wait for the service to start, and then repeat steps 2 and 3 for any other servers that you want running the Access Services service.

Creating the Access Services service

As soon as the Access Services service is running, you can create the Access Services service application. This is set up similarly to other service applications:

1. Navigate to Central Administration with a farm administrator account and click Manage Service Applications in the App Management section.

2. Click New and choose Access Services from the list of service applications.

3. In the Name section, enter an appropriate name (for example, Access Service Application).

4. In the New Application Database Server section, enter the name of the SQL Server 2012 instance where Access app databases will be created.

5. Leave Windows Authentication selected under the Application Database Authentication heading (unless your organization has specified a strong reason not to).

6. Leave Validate The Application Database Server selected if you want to check the SQL Server instance to ensure that it has been configured correctly.

7. In the Application Pool section, choose to use an existing application pool or create a new one.

8. Leave the default proxy list settings as is, unless you don’t want the proxy to show up in the default list. Click OK.

If the SQL Server instance hasn’t been configured correctly, you should receive an error message describing what you need to fix. If the instance has been configured correctly, the service application is created.

Configuring the application pool

After creating the Access Services service application, you still need to configure the application pool that’s used with the service application. You can perform this step earlier if you plan to use an existing application pool. The application pool needs to be configured in Internet Information Services (IIS), and the Load User Profile setting needs to be set to True. Follow these steps to configure the application pool:

1. In the Start text box, type IIS or select it from Administrative Tools.

2. Open the server where the application pool exists and click Application Pools.

3. Right-click the application pool that starts with a GUID and has multiple applications (the Access Services pool application also starts with a GUID but has only a single application) and select Advanced Settings.

4. In the Process Model section, select True for the Load User Profile setting.

5. Click OK and perform an IISRESET.

Creating a site collection

Now you need to create a site collection where users can create Access apps. The site collection is just a typical site collection based on any template you want (such as Team Site). This is the location that you specify when you create an Access app.

Confirming the settings

At this point, you should look at the configuration of the Access Services service application and make sure that the settings are in line with your business needs. Also, if you set up a SQL Server 2012 instance because SharePoint Server 2013 is installed on SQL Server 2008 R2, you need to specify the SQL Server 2012 instance in the settings of the service application. You need to make fewer decisions than with the Access Services 2010 application, but they can still have a major effect on the resources of your SharePoint farm. The following configuration items are available:

• Maximum Request Duration. The maximum amount of time, in seconds, allowed for a request. The default is 30 seconds. A value of –1 indicates no limit, and the maximum value is 2073600 (24 days).

• Maximum Sessions Per User. The maximum number of sessions allowed per user, with the oldest ones being deleted as new requests come in. The default is 10. A value of –1 indicates no limit, and the maximum is any positive integer.

• Maximum Sessions Per Anonymous User. The same as Maximum Sessions Per User, except it’s for anonymous users. The default is 25.

• Cache Timeout. The maximum amount of time, in seconds, that data can remain cached as measured from the end of the last request. Default is 300 seconds (5 minutes). A value of –1 indicates no limit, and the maximum value is 2073600 (24 days).

• Query Timeout. The maximum amount of time, in seconds, for a query to complete before it’s canceled. A value of 0 indicates no limit, and the maximum value is 2073600 (24 days).

• Maximum Private Bytes. The maximum amount of server memory that can be allocated by the Access Services process. A value of –1 indicates that up to 50 percent of the memory can be allocated. The maximum value is any positive integer.

• New Application Database Server. Where you can add a new database server (an additional server or the first one if you aren’t using the SQL Server instance on which SharePoint is installed). You enter the database information in the same way as when creating the service application (see Figure 4-5).

Figure 4-5. Adding an additional (or new) application server for Access Services

As with Access Services 2010, you should be thoughtful in how you modify the settings. Unchecked, Access Services can easily consume half of the resources available to the SharePoint farm just from a single user (depending on your farm’s configuration). If you expect heavy usage of Access Services, you should dedicate at least one SharePoint server to the Access Services service.

After you set up Access Services, users can start creating Access apps, as follows:

1. Open the Microsoft Access 2013 desktop application. (The Access Service service application doesn’t have an open API, so you can’t use code to create Access apps.)

2. Choose Custom Web App from the choice of templates.

3. In the Custom Web App dialog box, enter the App Name. For the Web Application, use the site collection you created earlier for the purpose of managing Access apps.

If an error occurs during app creation, you should go back and double-check all the steps to make sure that you didn’t miss anything. The Validate The Application Database Server option discussed earlier in the section Creating the Access Services service doesn’t catch all the required items.

More Info: What’s new in Access 2013?

See http://msdn.microsoft.com/en-us/library/fp179914(v=office.15).aspx to learn about the new features in Access 2013.

The Visio Services service application allows users to interact with Visio drawings. Users can load, display, interact programmatically with, and connect Visio drawings to the Business Connectivity Services. With SharePoint 2013, users can now save Visio files directly to SharePoint without having to export them to a Visio web drawing (.vdw). Users still need Microsoft Visio 2013 to save drawings this way, however.

Two different file types can be saved directly to SharePoint. The first file type has a .vsdx extension and is based on the Open Packing Conventions (OPC) standard. The second file type uses the XML-based file format with a .vsdm extension and is similar to the Visio 2010 file format. Both .vsdx and .vsdm files are displayed in raster format, whereas the .vdw files are displayed via Silverlight.

Be aware of several new features in Visio Services when configuring the service application. Diagrams can now be connected to external lists via the Business Connectivity Services. An additional related benefit is that the Visio diagrams can be refreshed as the data in the external lists is updated. Visio 2013 drawings can have comments attached to individual shapes and pages. This comment framework can be accessed through a JavaScript API allowing users to retrieve comments so they can be displayed on the web page.

Configuring Visio Graphics Service settings

After you create the service application, you should configure its settings to meet your organization’s needs. To configure the settings, open the Manage Services Applications page and clicking the service application you created. This takes you to the Manage The Visio Graphics Service page. The two sections on the page are Global Settings and Trusted Data Providers, as shown in Figure 4-6.

Figure 4-6. Setting categories for the Visio Graphics Service

Global settings

You should review the default global settings to ensure that they meet the needs of your organization. Like with most service applications, these settings can affect the performance of not just the Visio Graphics Service but also that of the entire SharePoint farm. The following global settings are available:

• Maximum Web Drawing Size. The size, in megabytes (between 1 and 50), of the largest web drawing that can be rendered. The default is 25 MB.

• Minimum Cache Age. The minimum number of minutes, between 0 and 34560 (24 days), that a web drawing remains in cached memory. The default value is 5.

• Maximum Cache Age. The maximum number of minutes, between 0 and 34560 (24 days), that a web drawing remains in cached memory. After this value, the cache is purged of the web drawing. The default value is 60.

• Maximum Recalc Duration. The amount of time, in seconds (between 10 and 120), before a data operation times out. The default is 60.

• Maximum Cache Size. The maximum size, in megabytes (between 100 and 1024000), that can be used for the cache. The default is 5120 (5 GB).

  Note: Boost the cache size

  While not as memory intensive as Excel or Access, Visio can still consume considerable resource in organizations where it’s used extensively. The default cache size of 5 GB can be a considerable burden on servers that have limited amounts of memory.

• External Data. Where the unattended service account is entered. Enter the application ID in the text box provided. It’s used whenever Visio connects to external data sources.

More Info: Configuring global settings for the Visio Graphics Service

See http://technet.microsoft.com/en-us/library/ee524061.aspx for more information on how to configure the global settings for the Visio Graphics Service in SharePoint Server 2013.

Trusted data providers

The second group of settings for the Visio Graphics Service service application is Trusted Data Providers. This list is similar to that in the Excel Services service application, but notice that several additional data providers aren’t part of the Microsoft suite of products. That this list of trusted providers is longer is probably because of Visio being more trusting of external data, due to the nature of what it can do (draw diagrams). One source is even for Excel Web Services, in case the values for some of the drawings exist in Excel workbooks. In fact, Visio Graphics Service allows for six different types of data providers for Excel, instead of just three.

If the data provider that you need isn’t available, you can add it by clicking Add A New Trusted Data Provider on the Visio Graphics Service Trusted Data Providers page and configure the following settings:

• Trusted Data Provider ID. The name used by Visio to connect to external data

• Trusted Data Provider Type. An integer between 1 and 6—1 for OLE DB, 2 for SQL, 3 for ODBC, 4 for ODBC with DSN, 5 for SharePoint Lists, and 6 for Visio Custom Data Providers—that specifies the type of data provider

• Trusted Data Provider Description. A description that appears in the Trusted Data Provider list

Word Automation Services enables users to automate the conversion of Word documents into other sorts of documents. You can think of it as a way to automate the Save As command. For example, if you want to convert thousands of word documents into single file web pages (with the .mht or .mhtml extension), you can use Word Automation Services. Enabling Word Automation Services begins by starting the Word Automation Services service application:

Microsoft PowerPoint Conversion Services is a new feature in SharePoint 2013. In concept, it’s similar to Word Automation Services in that it provides the capability for automated conversions of PowerPoint documents to other types of documents. For example, if you wanted to convert a series of PowerPoint documents to a series of JPG files, you could use PowerPoint Conversion Services to automate this. The following files are supported for conversion by PowerPoint Conversion Services:

PowerPoint Conversion Services can take these supported files and convert them into various formats, as follows:

The PowerPoint Conversion Services service application relies on the PowerPoint Conversion Service. If you expect to convert many files, you should probably have this service running on more than one server. If you expect heavy and regular conversion usage, you should dedicate one or more servers to running this service. You can start the service on the required servers by following these steps:

After you start the services on the servers, you need to create the PowerPoint Conversion Service service application. This can be done by running the Farm Configuration Wizard and choosing the PowerPoint Conversion Service Application in the list of service applications. (If this is the only service application that you want configured, make sure that all the other options that can be changed are cleared.) The Farm Configuration Wizard uses the default settings; if you don’t want to use the default settings or just prefer to use PowerShell, you can use the following commands to create the service application and its proxy:

$account=Get-SPManagedAccount "<account>"
$appPool=New-SPServiceApplicationPool -Name PowerPowerAppPool -Account $account
$appService=New-SPPowerPointConversionServiceApplication -ApplicationPool $appPool -Name
<ServiceName>
$proxyService=New-SPPowerPointConversionServiceApplicationProxy -ServiceApplication
$appService

After you create the PowerPoint Conversion Service service application and proxy, it’s ready to be used by programmers. You don’t need to configure any user settings.

The Machine Translation Services service application is a powerful new tool in SharePoint 2013 that allows documents to be sent to Microsoft for translation from one language to another. This can be done for files and pages as well as for whole sites. This remarkable new service allows owners of SharePoint to deliver much of its content in wide variety of languages. Architecturally, the Machine Translation Service is similar to the Word Automation Service in that it has timer jobs and queues.

Creating and configuring the Machine Translation service is a little more complicated than most of the service applications, mainly because it has to connect to the Internet. The following prerequisites must exist before you can use the Machine Translation service:

The App Management Service is probably already running on your server, but if it isn’t, you need to create the App Management Service service application and start the App Management service as you did when creating and configuring the App Catalog in Objective 4.1: Create and configure App Management.

$timerjob = Get-SPTimerJob "Machine Translation Service - Machine Translation Service
Timer Job"
$timerjob.Runnow();

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

The first step in planning to federate services is to determine what services need to be federated. In SharePoint, a service on a farm can be published, and then one or more farms can consume this service. You might have various reasons to federate services. For example, if you want every farm to be able to search the same sets of data (thus providing consistent search results), you would want to set up a farm just for Search so that each farm won’t crawl the same set of data and store duplicate indexes, thereby saving storage space, memory, and CPU. The business needs of your organization should determine which services to federate; however, only certain services can be federated:

SharePoint 2010 farms can also consume services from a SharePoint 2013 farm, but not the other way around. This allows for SharePoint 2010 farms to be migrated in stages but still maintain consistency and services. For example, the Managed Metadata service application could be migrated to the SharePoint 2013 farm, and SharePoint 2010 farms could still consume the migrated managed metadata. SharePoint 2010 farms can consume only the services available in SharePoint 2010. For example, because Machine Translation doesn’t exist in SharePoint 2010, the farm couldn’t consume that service.

To use federated services, the farms involved need to be set up to trust one another and then the services themselves need to be published and consumed. The order in which the process of federating service applications should occur is as follows:

Determining which services should be federated, which farms should be consumers, and which should be publishers is up to you and whoever else is architecting the farm. Switching to a federated service or switching back can take a considerable amount of time—hours or even days, depending on what data and/or settings need to be transferred to restore functionality. This would, of course, cause significant disruption in a production environment. To avoid these disruptions, try to test the scenarios that you might use before you implement them in production.

Before two SharePoint farms can federate service applications, they must trust each other. For the SharePoint farms to trust each other, trust certificates must be exchanged between them. The consuming farm needs to provide two trust certificates to the publishing farm:

Whereas the consuming farm needs to provide two trust certificates to the publishing farm, the publishing farm needs to provide to the consuming farm just one certificate: the root certificate. These certificates must be created, copied over to the corresponding server, and then imported. The act of exporting the certificates varies somewhat, depending on the type of certificate being exported. To export the root certificate on the consuming farm, follow these steps:

While you are in the SharePoint 2013 Management Shell, you can export the security token (the STS certificate). Use the following PowerShell commands, in which <STS Cert Path> is the path and filename where you want to create the security token (STS) certificate:

$stsCert = (Get-SPSecurityTokenServiceConfig).LocalLoginProvider.SigningCertificate
$stsCert.Export("Cert")|Set-Content <STS Cert Path> -Encoding byte

After you export the certificates, you need to copy the consuming farm certificates to the publishing farm and the publishing farm certificate to the consuming farm.

After the certificates are created and exchanged, you can manage the trust between the consuming SharePoint farm and the publishing farm. Managing trusts requires that trust be established between the two farms. Establishing trust is done by importing certificates on the respective servers. On the publishing farm, you must import both the root and the STS certificates from the consuming farm. On the consuming farm, you need to import just the root certificate from the publishing farm. These tasks can be accomplished using Central Administration or through PowerShell commands. To import the certificates on the publishing farm, follow these steps:

On the consuming farm, you would follow steps 1 through 6, except that you would choose the exported publishing farm’s root certificate and then click OK. You don’t need to import an STS certificate on the consuming farm, so you would leave the Provide Trust Relationship box cleared. When the two farms have their certificates imported, trust is considered to be established.

You can also use PowerShell commands to establish trust. To import the consuming farm’s root certificate onto the publishing farm, follow these steps:

That takes care of importing the root certificate. Now you need to import the exported STS certificate from the consuming farm. You can do this by staying in the SharePoint 2013 Management Shell and using the following PowerShell commands, where <sts cert path> is the location of the consuming farm’s STS certificate:

$stsCert=Get-PfxCertificate <sts cert path>
New-SPTrustedServiceTokenIssuer <name of consuming server> -Certificate $stsCert

The certificates on the publishing farm should be complete at this point. You can verify that they are set up correctly by looking at the Manage Trusts page in Central Administration. As with the Central Administration method, the consuming farm needs to import only the publishing farm’s root certificate, and you can use the same set of PowerShell commands as you did on the publishing farm (except that you would use the path to the publishing farm’s exported root certificate and use a unique name that represents the publishing farm).

Before a consuming farm can actually consume any service applications from a publishing farm, the publishing farm has to give the consuming farm permissions to the Application Discovery and Load Balancing service application. After this is complete, the publishing farm can give permissions to the consuming farm for other service applications. Setting permissions on the publishing server can be done either in PowerShell or in Central Administration, but in either case you need the consuming farm ID, which you must obtain by using PowerShell commands. Follow these steps:

Now that you have the ID of the consuming farm, you can provide permissions to the Application Discovery and Load Balancing service application. This can be done on the publishing farm using PowerShell commands as follows:

If you want to use Central Administration (and save yourself a lot of typing) to set permissions on the Application Discovery and Load Balancing service application, you still need the consuming farm ID that you got from PowerShell earlier in this section. Assuming that you have the ID available, you can set permissions by following these steps:

After permissions are added to the Application Discovery and Load Balancing service application, you need to add permissions in the same way in Central Administration to any of the service applications that you want to publish to the consuming farm. If you want to use PowerShell commands to add these permissions, you would use similar commands as the earlier ones but instead use the service application’s GUID with Get-SPServiceApplication, not Get-SPTopologyServiceApplication.

By now, you’ve exchanged certificates between the consuming and publishing farms, imported the certificates, and set permissions on the service applications. Now you need to actually publish the service applications so that they can be consumed by one or more farms.

The act of publishing a service application provides a Universal Resource Name (URN) that can be passed to consuming farm(s). This URN provides schema and authority information needed by the consuming farm.

You can use either Central Administration or PowerShell commands to publish service applications. The following steps use the Central Administration method:

The service application should be published at this point and you should have the published URN for use on the consuming farm. If you didn’t set up your trust with the consuming farm(s) earlier, you could have done it from the Publish Service Application dialog box by clicking the Click Here To Add A Trust Relationship With Another Farm link. You can also publish a service application by using PowerShell commands, as follows:

Now you should be ready to start consuming service applications and using that functionality on the consuming SharePoint farm. To consume a service application, you need the published URN from the service application on the publishing farm. You can use Central Administration or PowerShell commands to consume the service application. If you want to consume the service application with Central Administration, follow these steps:

The remote service application should be available for use now if everything is configured correctly.

If you want to use PowerShell commands to connect to the remote service application, follow these steps:

At this point, you should be able to consume the service application. If an error occurred in the configuration, you need to pinpoint it starting with the trust certificates, then going to permissions, and also verifying that you’re using the correct published URL. All these items have to be done without error for federation to work. Troubleshooting can be difficult, so it might be easiest to start over from the beginning if it’s not working.

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

BCS models—also known as Business Data Catalog (BDC) models—are XML files that describe an external data source. The XML file outlines the data available, the data type, and the data location for one or more external content types. The BCS model can be used with a wide variety of different types of data sources:

The ability to use OData data sources is new to SharePoint. SharePoint lists have been available as OData to other programs that can consume OData sources, but this is the first version of SharePoint that has built-in support for consuming OData. Data is accessed with OData by using a specially formed URL.

After a model is created and imported, the BCS can expose the data as a SharePoint list, use it in a SharePoint application, or even use it in Microsoft Office 2013. The BCS models can be created with SharePoint Designer or with Visual Studio. Depending on permissions and how the BCS model is designed, users can create, read, update, and delete data (known as CRUD operations). Users can also create queries that use the data. Regardless of how a model is created, it can be imported into the Business Data Connectivity Services (BDCS) service application using Central Administration or with PowerShell commands. To import a BCS model using Central Administration, follow these steps:

After you import the model, it appears on the Business Data Connectivity page. Notice that three views can exist on the page: BDC Models, External Systems, and External Content Types. If you don’t see the data you are expecting, check to make sure that the view is correct.

You can also import models by using PowerShell commands in the SharePoint 2013 Management Shell, assuming that the account used has the proper permissions. You need to get a reference to the metadata store using the command Get-SPBusinessDataCatalogMetadataObject and then use the command Import-SPBusinessDataCatalogModel to import the model into the BDCS service application. In the following example, <context> is a web app that uses the metadata store you want to associate your model to (such as http://contoso) and <BDCM Path> is the file path to the exported model (for example, c:model.bdcm):

$meta=Get-SPBusinessDataCatalogMetadataObject -BdcObjectType "Catalog" -ServiceContext
<context>
Import-SPBusinessDataCatalogModel -Path <BDCM Path> -Identity $meta

As soon as a model is in the Business Data Catalog service application, it can be exported out. You might want to do this when you are moving from development to production or from one farm to another. If you created the model with SharePoint Designer 2013, you should use that to export the model. If you created the model with Visual Studio, you can import through Central Administration or through the SharePoint 2013 Management Shell by using the PowerShell command Export-SPBusinessDataCatalogModel.

To use Central Administration to export a BDC model or resource file, follow these steps:

The BCS uses profile pages to enable end users to see data related to a particular record. For example, a user could see all the details related to a catalog item such as price, quantity, weight, and so on. All the data related to the particular record appears on the profile page just by clicking the View Profile Action link that shows up on any SharePoint list where the business data is displayed. You can set the location of where the profile pages will reside, which can be any SharePoint site in the farm, but for maintenance and security reasons you are recommended to use one site for all the profile pages used by the BCS. You don’t have to enable profile page creation, but if you do, you need to specify a location. To configure profile pages for a BCD model, follow these steps:

After you supply a Host SharePoint site URL and enabled profile page creation, you can create the profile pages by following these steps, assuming that you are already on the Business Data Connectivity Service Application properties page:

In a situation where profile pages already exist, they are either upgraded or replaced. If they are replaced, you will lose any customizations. If they are being upgraded from SharePoint 2010 profile pages, they are simply upgraded; if they are being upgraded from SharePoint 2007 profile pages, a new action, called View Profile (SharePoint 2007), is added to point to the old profile page. View Profile points to the newly created profile page.

Profile pages are regular SharePoint pages that can be modified after they are created. You can provide additional information about the record, modify the look and feel of the page, and put links to more information on the page. You can add/remove web parts and customize the page to fit your organization’s needs. You can also modify the templates on which the profile pages are based, but remember that all future profile pages will use these modified templates.

Security in general should be kept to a least-privileged model. This means that only those users who need access to a BCS model (also known as a BDC model) and the components associated with it (External Systems and External Content Types) should have access to it.

Depending on the size and complexity of your organization, you probably don’t want the SharePoint farm administrators to manage the security on the BCS models. In fact, you might not want the farm administrators to have anything to do with the management of the BCS models. As a BCS administrator, you can apply permissions to each of the following items directly:

The BDC models, external systems, and external content types are all stored in the metadata store. It not only provides a place for storage but also a mechanism for permissions inheritance. If a BDC model, external system, or external content type isn’t given explicit permissions, they inherit their permissions from the metadata store. An external content types can also inherit its permissions from the external system to which it’s connected.

Permissions inheritance can happen in one of two ways. Whenever an item is added, it automatically inherits the permissions of the metadata store. You can also forcibly overwrite any set of custom permissions by using the Propagate Permissions To All option when modifying the metadata store permissions. To modify the metadata store permissions, follow these steps:

You can make changes to each of the three components (BDC Models, External Systems, and External Content Types) individually depending on your organization’s security needs. You would set the permissions similarly, but you would first select the view corresponding to the item that you want to change (such as BDC models) and then select the items to which you want to assign permissions. After selecting the items, click Set Object Permissions in the Permissions section of the EDIT tab on the ribbon. Then add users and permissions in the same way as you would with the metadata store. Any set of permissions that you set on the object will override the permissions set at the metadata store level unless the permissions are forcefully propagated down. The types of permissions and what they mean are as follows:

Having a very limited set of users (or even just one user) at the metadata store level is generally advisable, and as is using the Propagate permissions to all early on and then not use it again. For the individual objects, give permissions explicitly to the users that are responsible for how the objects will be used. Periodically, you should review the permissions on all objects in BCS as you would with any secured area of your organization.

The Secure Store is a service application that provides an authorization service to other service applications. Credentials are stored securely in a database on the SQL Server instance that the SharePoint farm uses. The BCS uses the Secure Store to provide secure access to external systems that don’t use Active Directory or use Active Directory but want to impersonate as a different user. The security placed on BCS objects has no relation to the permissions that are set in Secure Store.

Before the BCS can start using the Secure Store, a master key needs to be generated. This master key is used to encrypt the credentials so that even if someone had access to the Secure Store database, they couldn’t retrieve the credentials. After the Secure Store service application is created, you need to create the master key:

After you generate a new key, you should back up both the Secure Store database as well as the Secure service itself (which contains the key). These backups should be stored in separate locations for security reasons; the key is necessary to decrypt the database. If a new key is generated, you should repeat the backup process so that the backups of the key and the database are kept in sync.

You use Central Administration or PowerShell commands to back up the Secure Store service. To back up the service with Central Administration, follow these steps:

You can back up the Secure Store service application with PowerShell also. As with the Central Administration backup method, the backup should be done locally for performance reasons but then it should be moved to a separate secure location. You can use the following PowerShell command in the SharePoint 2013 Management Shell to back up the Secure Store service application, where <path> is the network folder location and <service name> is the name of the Secure Store service application:

Backup-SPFarm -Directory <path> -BackupMethod Full -Item <service name>

If for some reason the key is compromised, a new one should be created. If this is done, any backups of the old Secure Store database and any backups of the old Secure Store service application (which contains the key) should be deleted as well, assuming that new backups have been done.

Managing the Secure Store master key means keeping the backed-up key (the backup of the Secure Store service application) and the passphrase in a secure location and, if necessary, restoring the master key. Keeping the master key and passphrase in a secure location depends on your organization and the options that you have available. Storing it on physical media such a thumb drive and putting it in a locked storage area is recommended.

You might need to restore the Secure Store service application (and therefore the master key) if the key is compromised or the service application becomes corrupted because of hardware or software failures. You can use Central Administration or PowerShell commands to restore the Secure Store service application, but in either case you need the passphrase. To perform the restore operation using Central Administration, follow these steps:

After you restore a Secure Store service application, you should probably generate a new key and do another backup.

If you want to use PowerShell commands to restore the Secure Store service application, you can do so by using the following commands in the SharePoint 2013 Management Shell, where <service name> is the Secure Store service application name, <path> is the folder where the backup is stored, and <passphrase> is the passphrase:

Restore-SPFarm -Directory <path> -Item <service name> -RecoveryMethod Overwrite
Update-SPSecureStoreApplicationServerKey -Passphrase <passphrase>

This method restores the most recent backup (if more than one exist). To retrieve a specific backup, use the PowerShell command Get-SPBackupHistory.

A target application is defined as a collection of information used to map a user or group of users to a set of credentials that’s used to access data. The user name and password stored in the credentials is what’s used to access the external data, instead of the user’s credentials used to access SharePoint. The following information is stored as part of the target application:

One of the most import decisions when creating a target application is whether to use individual mappings or group mappings. Individual mapping is when each user has a unique set of credentials, whereas group mapping is where everyone has the same set of credentials. You can use individual mapping when you want to keep logging information about the user, but doing so requires more resources. Group mapping uses fewer resources and requires less work, but everyone is treated as the same person.

The second main decision to make is who will access the target application and therefore be able to use it and its account. After you open the target application to users, they can use it on multiple SharePoint solutions, potentially overloading the external system that it’s accessing.

Target applications can be created within the context of the Secure Store service application. Follow these steps:

The target application is ready to have its credentials set at this point (and any of the other fields added). Unless you are working with customized solutions, you should stick with either Individual or Group for the Target Application type. The Ticketing options are used with systems that can use tickets and requires the IssueTicket and GetCredentialsUsingTicket methods to be used in the code accessing the external system. The Restricted options are used when the code calling the external system requires a restricted context.

Target applications have two different types of applicable permissions: permissions that determine who can administer the target application and credentials that are set for access to the external data. The permissions on who can administer a target application are entered when it is created. You can change these permissions at any time, though, by using Central Administration. Follow these steps:

The next permissions-related item is setting the credentials. The default type of credentials is Windows (Active Directory), but several different types of credential types can be used, such as the following:

Whatever type of credentials you choose, you need to set the values along with the values of any fields that have been added. These additional fields could be items such as default language or which database to use. You can set the values for these fields in the Secure Store service application. Follow these steps:

This example showed a target application type of Individual. This set of credentials would map to an individual, and each individual who wanted to use the target application would need her own set of credentials. If it had been a target application type of Group, the credential members would be shown but you couldn’t edit them here; you would have to edit the target application to change the members.

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

In this thought experiment, you were asked what it would take for an App Catalog to remain available even though a SharePoint server was down for maintenance or because of hardware failure. The purpose behind this thought experiment was to reiterate the concept of high availability regarding apps.

First, you would probably want to take is to make sure that the App Management Services service application and the Microsoft SharePoint Foundation Subscription Settings Service service application are both running on more than one server. This ensures that the services needed by the App Catalog are available.

Second, you would want to make sure that more than one front end are available for and DNS entries that you created for use by the App Catalog. This should enable the App Catalog to be highly available so that users can get to the apps they need, even when a server is down.

In this thought experiment, you were told to figure out how to solve the slowness experienced by end users without compromising the Word conversion project. By default, the Word Automation Services service consumes 100 percent of the available memory on the servers that run the service. You could lower this percentage to give other applications more memory and ease up the load on the application servers, but this will probably slow down the Word conversion project. Another solution might be to delay the Word conversions until after hours or on the weekends. This might be a solution if you work with the developers to delay the requests and add only enough conversions so that they finish before the users come into work.

Perhaps the best solution is to use one of the WFEs as a dedicated Word Automation Services server and remove the service from the application servers. Because the WFEs aren’t even being used at 50 percent, removing one of them would still provide redundancy and the WFEs still wouldn’t be maxed out. Because the Word Automation Services server wouldn’t have to compete with other applications on the WFE server, it would most likely provide even better performance than if it was running on the both of the application servers. You wouldn’t have redundancy, but if the server should happen to fail, you could always start it up on one of the other SharePoint servers until it could be replaced or repaired.

In this thought experiment, you were asked what steps would be required to be able to use the Search service of a SharePoint 2013 farm by an unspecified number of SharePoint 2010 farms. The steps required for connecting one consuming farm to one publishing farm were covered in the objective. The process for connecting more than one consuming farm is basically the same procedure repeated for each farm. You have to create the publishing farm root certificate only once. The same certificate can be used on all the consuming farms.

To use the Search service, follow these steps:

At this point, the consuming farms should be able to use the SharePoint 2013 farm’s Search service just as they would their own Search service. Management of any search settings needs to be done on the SharePoint 2013 farm, and any Search service crawling account needs permissions on the SharePoint 2010 farms to crawl them.

In this thought experiment, you were asked to provide a way to expose a user’s contacts from Windows Live in a SharePoint list. Because Windows Live is an OData provider, you can use OData as your data type when you create the BCD model. This most likely is the most straightforward way to reach this goal.

You need Visual Studio 2012 to create the OData model because SharePoint Designer can’t create OData models. You would create the model defining the Windows Live data source and then import it into the Business Data Connectivity service application. You would then provide permissions to the model and use Secure Store to provide pass through authentication. SharePoint Designers could then use an external content type to expose the contact information in a SharePoint list.

Using REST to expose the Windows Live data would also be possible because Windows Live exposes its endpoints via REST. Another option would be that a programmer could write a .NET assembly that pulls data from Windows Live and exposes it as SharePoint list data. However, OData is being embraced by SharePoint and, going forward, will likely be the most compatible with future releases. It’s also an open system that’s used by other organizations, so it is likely to become even more prevalent.