Sandboxed solutions run as a very restricted set of code. The whole purpose of the sandboxed solutions was to allow deployment of solutions that wouldn’t affect the rest of SharePoint. For example, an errant web part couldn’t take all the resources of the SharePoint farm. SharePoint accomplishes this by making all the sandboxed solutions run within the User Code Service and by setting quotas on how much of the system resources the sandboxed solutions could consume.

Quotas are set at the site collections level both for the amount of space they can use and how many points can be allocated to sandboxed solutions. When a sandboxed solution or set of solutions uses up the resource points within a single day, all sandboxed solutions in the site collection are stopped until the Solution Daily Resource Update timer job runs (typically late at night or early morning) or the quota is removed or increased.

Determining the resource quota for sandboxed solutions is accomplished by modifying an individual quota for a site collection or by modifying or creating a quota template and then applying it to a site collection. When modifying a quota, you set the maximum number of points that can be used by all sandboxed solutions that run in the site collection before sandboxed solutions are disabled. You can also set a warning level that sends out an email as soon as it has been reached. You can set the quotas for an individual site collection in Central Administration by following these steps:

In these steps, you could have chosen a template rather than sett directly for an Individual Quota. You can also set a quota template by running the following PowerShell command in the SharePoint 2013 Management Shell, where <site collection> is the URL or GUID of the site collection and <template name> is the name or the GUID of the template:

Set-SPSite -Identity "<site collection" -QuotaTemplate "<template name>"

In the quotas, you were setting the number of points that could be accumulated in a day before the sandboxed solutions were disabled. A point is determined by a collection of up to 15 resource counters. For example, after the sandboxed solutions in a site collection use up a certain number of CPU cycles, that counts as a point and is added to the total for the day. As a farm administrator, you can change what these values are by using PowerShell commands. You can see the current resource point allocations by using the following PowerShell commands as a farm administrator in the SharePoint 2013 Management Shell:

$rpa=[Microsoft.SharePoint.Administration.SPUserCodeService]::Local
$rpa.ResourceMeasures | Select-Object Name,ResourcesPerPoint,AbsoluteLimit

Running the commands lists the names of the resource measures, the amount of resources per point, and the absolute limit of points per resource:

Name                                ResourcesPerPoint             AbsoluteLimit
--------------------------------------------------------------------------------
AbnormalProcessTerminationCount                     1                         1
CPUExecutionTime                                  200                        60
CriticalExceptionCount                             10                         3
IdlePercentProcessorTime                          100                        10
InvocationCount                                   100                       100
PercentProcessorTime                               85                       100
ProcessCPUCycles                         100000000000              100000000000
ProcessHandleCount                              10000                      5000
ProcessIOBytes                               10000000                 100000000
ProcessThreadCount                              10000                       200
ProcessVirtualBytes                        1000000000                4000000000
SharePointDatabaseQueryCount                      400                       100
SharePointDatabaseQueryTime                        20                        60
UnhandledExceptionCount                            50                         3
UnresponsiveprocessCount                            2                         1

You can use the names in the preceding list to modify the values if you want to change the respective weights of the resources. For example, you might want to make CPU execution time more important than Process IO Bytes. You would do this by lowering the CPUExcecutionTime property from 200 down to something less, like 100, so that the points would accumulate twice as fast as they did before you changed it. You can change the values of the resource measures in the same Management Shell by using the following PowerShell commands, where <resource name> is the name of the resource measure to be changed, <limit value> is the absolute limit value, and <point value> is the resource per point value:

$rpa=[Microsoft.SharePoint.Administration.SPUserCodeService]::Local
$rpa.ResourceMeasures["<resource name>"].AbsoluteLimit = <limit value>
$rpa.ResourceMeasures["<resource name>"].ResourcesPerPoint = <point value>
$rpa.ResourceMeasures["<resource name>"].Update()
$rpa.Update()

Whatever values you use, you might want to keep track of the points by referring back to the Configure Quotas And Locks page to see how many points are being consumed. Any sandboxed solutions that you are using and deem as valuable in the long term for your business should be marked for migration to an app solution or a farm solution if an app solution isn’t feasible.

Sandboxed solutions (or user solutions, as they are sometimes called) can be managed at the farm level. Since SharePoint 2010 introduced sandboxed solutions, they have been the preferred development solution. Thousands and thousands of sandboxed solutions are available.

Even though SharePoint 2013 recommends that you now use SharePoint apps instead of sandboxed solutions, most organizations won’t have enough time and/or money to convert these applications before upgrading to SharePoint 2013. This means that you need to test and manage these solutions as they are migrated to the new farm(s).

The preceding section covered setting quotas, which can limit how many resources are used by sandboxed solutions per site collection. Sandbox Solution Management allows for blocking of certain sandboxed solutions as well as determining how servers are used to provide resources. This way, you can remove certain solutions that might be consuming more resources than they should be without affecting the other solutions. It also allows you to determine which servers are used to provide solution services. To delete sandboxed solutions, follow these steps:

In the Load Balancing section, the option to run the sandboxed code on the same server as requests can help improve performance and requires that all WFEs run the Sandboxed Code Service. If you want to specify servers to run the Sandboxed Code Service, you need to use the Requests To Run Sandboxed Code Are Routed By Solution Affinity option. This can also help you isolate the sandboxed solutions so that they don’t potentially use many resources on the WFEs, but doing so also can cause something of a performance hit because the WFEs have to communicate across servers.

Farm solutions are also known as full trust solutions because they have full trust on the servers on which they are installed. When you deploy a farm solution, it can place the dynamic link libraries (DLLs) that it uses in the global assembly cache (GAC). This gives farm solutions a high degree of access to the server.

Only fully tested and trusted farm solutions should be deployed into a production environment. Despite the push for SharePoint apps, server-side code is still needed for many solutions, which means that you will continue to need to deploy farm solutions.

Deploying farm solutions is much more different in SharePoint 2013 from what it is in SharePoint 2010, because of the ability of SharePoint 2013 to run SharePoint 2010 mode alongside SharePoint 2013 mode. SharePoint 2013 accomplishes this by having different areas in the root folder. It has a folder that starts with 14 for SharePoint 2010 files and a folder that starts with 15 for SharePoint 2013 files.

If you deploy a farm solution in the same way that you did in SharePoint 2010—by using the PowerShell commands Add-SPSolution and Install-SPSolution—the farm solution files that are part of the TEMPLATES directory are installed only under the 14 folder and therefore aren’t accessible to SharePoint 2013 mode. The files that aren’t part of the TEMPLATES directory are still installed in the same places they were in SharePoint 2010—that is, in binaries, DLLS, ISAPI files, and so on. If you want the farm solution files available to both the SharePoint 2010 mode and the SharePoint 2013 mode, you need to install the files into both folders.

SharePoint 2013 uses the CompatibilityLevel property that you can include as part of the Install-SPSolution command or define in the solution file (although values in the solution file will be overridden by those of the Install-SPSolution command). Following are the valid values for the CompatibilityFile property:

If a solution file doesn’t contain a Compatibility Level property, it defaults to 14. You can install a farm solution into both the 14 and 15 folders with a single command; if you try to install a solution by using two different commands, you will get an error. If you try to use the -Force option, you can cause the solution to malfunction. You should uninstall it by using the Uninstall-SPSolution and then reinstall by using the “14,15” or the “All” Compatibility Level, as shown in the following example where <solution name> is the name of the solution:

Install-SPSolution -Identity <solution name> -CompatibilityLevel "14,15"

To have functionally different solutions for the SharePoint 2010 and SharePoint 2013 modes, you should create two different solutions and make sure that their compatibility levels are different. If you want two different solutions but also want them to share a set of global files, you can create three solution files: one set for files that go in the 14 folder, one for files that go in the 15 folder, and one for files that are shared globally.

If you want to use Central Administration to deploy a farm solution and want to control what folder the solution is deployed into, you need to set the version in the solution itself. This is done by setting the SharePointProductVersion attribute of the Solution property in the solutions manifest file (manifest.xml). Now, the only valid values for SharePointProductVersion are 14.0 and 15.0. By default, if no version is set, SharePoint 2013 assumes that the solution will be installed into the 14 folder. You can add the SharePointProductVersion attribute to the manifest files if you want ensure that people installing it with Central Administration install it into the right folder. If you want to install (deploy) it into both the 14 and the 15 folders, you need to use the PowerShell command Install-SPSolution or create two solutions. If you still want to deploy your farm solution with Central Administration, add it first by using the PowerShell Add-SPSolution command and then follow these steps:

This exam doesn’t cover programming, but you need to be aware of some aspects of upgrading farm solutions. The good thing about bringing farm solutions over to SharePoint 2013 is that most of them will run because of the separate 14 and 15 folders. The farm solution defaults into the 14 folder when it’s installed. That the solution might even be available in SharePoint 2013 mode is highly likely. You should still upgrade your farm solutions when you can, though. SharePoint 2013 uses .NET 4.0 and if you want your farm solutions to be natively compatible with SharePoint 2013, they need to be compiled with .NET 4.0. If you want the farm solution to be deployed to the 15 folder, follow these steps to modify your old solution:

After rebuilding a solution, you need to deploy it, upgrading the solution to the most current version. When upgrading a farm solution, you have two options: replace or update.

In the replacement method, the solution is retracted and optionally removed. The new solution is then added and deployed. If you uninstalled but didn’t remove the solution, you need to use a new (and unique) filename for the .wsp file and a new GUID. If you plan to install the solution into the same folder, you should use the replacement method if any of the following is true:

When updating a farm solution, SharePoint automatically detects that the GUID already exists and retracts the existing solution before deploying the new solution. It keeps a backup of the old solution in case the new one fails to deploy (only one copy of a backup is kept at a time). You use the Update-SPSolution PowerShell command to perform this type of upgrade. You can update a 14 solution in the 14 folder or a 15 solution in the 15 folder, but you can’t cross the folders because it must contain the same set of files and features as the existing solution.

Chapter 4, covered the topic of creating an App Catalog. The App Catalog stores apps that SharePoint users can then install on their SharePoint sites. An App Catalog is scoped to the web application level, so any apps that you want to be available to a site must be in the App Catalog that’s for the web application that contains the site. Adding a SharePoint app to the App Catalog can be done by navigating to the App Catalog site and following these steps:

An App Catalog is scoped to the web application level, but that doesn’t mean that only one web application can use it. An App Catalog can be used by all or several of your web applications. This means that you can use a single App Catalog for all the web applications on the SharePoint farm. This has a drawback in that you might be showing users SharePoint apps that aren’t applicable to the web application, but it has the benefit of allowing for app management in a single location. If you have an App Catalog per web application and want a particular SharePoint app to be available to all web applications, you have to add it to each App Catalog. If you want to attach an App Catalog to a different web application, you can do so in Central Administration by following these steps:

A SharePoint app package can contain various items, depending on where it’s located (that is, where the code runs). If an App runs in the cloud, the app package might consist of only an app manifest, which contains a product ID and a version number. For you to update an app the product ID must be the same as the existing app that you want to upgrade, and the version number must be higher. Migrating from an old app to a new one is also possible. In the migration scenario, the app would have a different product ID but could still have the same friendly name. In either case, you upgrade an app the same way that you deploy it for the first time.

After a SharePoint app is updated, end users will see an indication that an update is available on the Site Contents page of every web site on which the app is installed. Clicking the link to update the app starts the update process, and if it fails, it’s completely rolled back. The following series of events will occur in no particular order and, in some cases, will even occur in parallel:

Any updates that SharePoint 2013 can’t make need to go in the PostUpdate web service or in the first-run logic (code that runs the first time the app is run but not after that). This process of updating app code gives more power to end users (or to the site owner, at least) and away from farm administrators. This means that additional communication is needed for site owners to be aware of any app updates.

Migrating an app to a new one requires that the app use a new product ID in its manifest. Although the new app can have the same friendly name as the old app, they both will show up in the App Catalog as two distinct apps until the old app is removed. If data needs to be migrated, it needs to be handled by the app code via the PostInstall event, which runs after the app is installed. The new app can use any components (such as external data sources) that aren’t installed by the old app because when the old app is removed, it also removes any components that were installed with it.

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 SharePoint Server 2013, the PerformancePoint service application can be used to create BI dashboards. These dashboards can contain custom reports, key performance indicators (KPIs), filters, tabular data sources, and scorecards made up of SharePoint data as well as data from external sources.

You need to start the PerformancePoint service, create the PerformancePoint service application, and configure it before you can start using PerformancePoint services. Follow these steps:

SharePoint lets you know when the creation process is completed by displaying the screen shown in Figure 5-3, indicating that the PerformancePoint service application has been created, the steps necessary to complete the configuration, and a warning about connecting to Microsoft SQL Server Analysis Services.

Figure 5-3. PerformancePoint Service Application confirmation page

You also can create the PerformancePoint service application by using PowerShell commands in the SharePoint 2013 Management Shell.

SQL Server Reporting Services can be used in SharePoint 2013, assuming that both SQL Server and SharePoint have been configured correctly. After Report Services is configured, SharePoint can display and interact with SQL Server reports. This provides end users access to these reports without giving them access to the underlying data used to generate the reports. It also allows the full power of SQL Server to be used to generate reports (such as those based on millions of lines of data and/or complex relationships) that might not otherwise be feasible if they were pulled from SharePoint lists. Some reports have to be generated periodically rather than on demand. Regardless of the type of report created, it can be exposed within SharePoint.

Before you start configuring Reporting Services in SharePoint, you need to install it on the SQL Server instance that will provide Reporting Services to SharePoint (SQL Server can provide reports without SharePoint using Reporting Services).

Provisioning subscriptions and alerts

After creating the SQL Server Reporting Services service application, you should go ahead and provision subscriptions and alerts. Doing so requires that the SQL Server Agent run on the SQL Server instance that will host the Reporting Services databases. You also need to download a script and enter credentials for the account used to access the SQL Server Agent. The account needs sufficient permissions to grant the RSExecRole execute permissions to the following databases:

• Reporting Services service application databases

• MSDB

• Master

The Provision Subscriptions and Alerts page should look similar to Figure 5-8. It shows you whether the SQL Server Agent is running, gives you a link to download the necessary script, and provides a place to enter the necessary credentials.

Figure 5-8. Subscriptions and alerts page for provisioning

After the SQL Server Agent is started on the SQL Server instance that hosts the Reporting Services database(s) and an account is provided to allow Reporting Services to use the SQL Server Agent, you should execute the script that was downloaded. You can do this through SQL Server Management Studio:

1. Open an instance of SQL Server Management Studio with an account that has appropriate permissions (same or higher than those of the credentials that were entered on the Provision subscriptions and alerts page).

2. In the Connect To Server dialog box, enter the name of the server hosting the Reporting Services database(s) in the Server Name text box, select Database Engine from the Server Type list, and select an authentication mode (and enter credentials if necessary).

3. Click Connect.

4. From the toolbar of SQL Server Management Studio, choose File | Open | File.

5. Navigate to the downloaded script (for example, SQL Server Reporting Services Application-GrantRights.sql), select the file, and click Open.

6. Click the Execute icon and wait for the command to complete successfully.

At this point, the subscriptions and alerts for SQL Server Reporting Services (SSRS) service application provisioning should be done. You also can generate the script with PowerShell and to run the script with the command line.

More Info: Provisioning subscriptions and alerts for SSRS service applications

See http://msdn.microsoft.com/en-us/library/hh231725.aspx for more information on how to provision subscriptions and alerts for SSRS service applications.

Configuring Reporting Services

Reporting Services is up and running at this point (or should be) but still needs to be configured. Several options can be configured, as shown on the Manage Reporting Services Application page in Figure 5-9. You can get to the page via Central Administration by navigating to Manage Service Application in the Application Management section and clicking the name of the Reporting Services service application (for example, SQL Server Reporting Services Service Application).

Figure 5-9. Manage Reporting Services Application page

Configuring system settings

The first link you should visit is on the System Settings page, which offers the settings shown in Table 5-1.

Table 5-1. System Settings for configuring Reporting Services

Setting	Page section	Description
External Images Timeout	Reporting	Determines the length of time, in seconds, before a timeout occurs when retrieving external images. The default value is 600 (10 minutes). The range is any positive value.
Snapshot Compression	Reporting	Defines how snapshots are compressed: SQL, None, or All.
System Report Timeout	Reporting	Determines the time, in seconds, before a report times out. It can be overridden at the report level. The default is 1800 (30 minutes). A value of –1 is for no limit, and the max is any positive integer.
System Snapshot Limit	Reporting	Sets the maximum number of snapshots stored for a report. The default is –1 (no limit), and the range is any positive integer.
Stored Parameters Lifetime	Reporting	Determines the number of days that stored parameters can be stored. The default is 180 days, and the range is any positive integer.
Stored Parameters Threshold	Reporting	Determines the threshold, in days, for a parameter. The default is 1500 days. The range is any positive integer.
Session Timeout	Session	Determines the length of time, in seconds, that a session remains active. The default is 600 (10 minutes), and the range is any positive integer.
Use Session Cookies	Session	Indicates whether cookies can be used when communicating with client browsers. This option is selected by default.
RDLX Report Timeout	Session	Determines the amount of time, in seconds, before an RDLX report times out. The default is 1800 (30 minutes), and the range is any positive integer.
Enable Execution Logging	Logging	Lets you choose whether to enable report execution logging.
Execution Log Days Kept	Logging	Determines how many days to keep report execution information. The default value is 60 days, and valid values are –1 to any positive integer. A value of 0 indicates that entries won’t be deleted.
Enable Integrated Security	Security	Determines whether integrated security is enabled.
Enable Load Report	Security Definition	Determines whether users can perform impromptu queries from a Report Builder report.
Enable Remote Errors	Security	Determines whether remote information is included with the error messages returned from remote computers. This setting is disabled by default.
Enable Test Connection Detailed Errors	Security	Determines whether detailed error messages are sent to the client computer when the data source connection is tested.
Enable Report Builder Download	Client	Indicates whether users can download Report Builder from sites in the SharePoint farm.
Report Builder Launch URL	Client	Requires a URL if the Report Service doesn’t use the default Report Builder URL.
Enable Client Printing	Client	Specifies whether the RSClientPrint ActiveX control is available for download from the report server. Note that some browsers and/or browser settings can prohibit ActiveX controls.
Edit Session Timeout	Client	Specifies the number of seconds before a report edit session times out. The default is 7200 (2 hours), and the range is any positive integer.
ExecutionLogLevel	User-Defined	Defines the execution log level with a default of Normal. The other valid option is Verbose.

Managing Jobs

Clicking the Manage Jobs link of the Manage Reporting Services Application page takes you to the Manage Jobs page, where you can view any running Reporting Services jobs. You can also select jobs to delete on this page (for example, if a particular job or set of jobs is taking too long). This page has nothing to configure, but if you set your timeout to be particularly high, you might need this page to end errant jobs.

Managing Keys

The next link on the Manage Reporting Services Application page is Key Management. SharePoint encrypts the data in the Reporting Services databases with an encryption key that you can back up, restore, and change.

If you have to restore a Reporting Services service application, you also need to restore the encryption key. When you back up the encryption key, you provide a password that must meet the complexity requirements set by the domain policy. This password is also needed to restore the encryption key, so keep it in a safe location separate from the backup of the encryption key. For security purposes, you should also store the encryption key in a physically separate location from the SharePoint farm as well as from the backups of the Reporting Services service application. You should change the encryption key occasionally, but the process can take several hours depending on the amount of content. Therefore, you should schedule this so that users are minimally affected, and you should back up the key immediately after changing it (as well as back up the service application itself, because the two backups work in tandem).

The final option on the Key Management page is to delete encrypted content. Deleted content (which can include stored connection strings, subscription information, and information necessary to connect to external data sources) can’t be recovered after it’s deleted. This action is non-reversible, so make sure that users aren’t caught unaware by it. All four actions—backup, restore, change, and delete—are available on the Key Management page, as shown in Figure 5-10.

Figure 5-10. Key Management page of the SQL Server Reporting Services service application

Configuring the Execution Account

The fourth item on the Manage Reporting Services Application page is the Execution Account. This account is used when connecting to data sources that don’t use credentials or when connecting to another server to retrieve external image files or resources. The account is also used when a data source specifies None as the credential type. It shouldn’t be the same account used to run the Reporting Services service because of security concerns. Also, it should have minimal access, such as read-only, if any access at all is required (to external servers, for example).

You are recommended to use a domain user account that has network logon permissions, so that it can access other servers. You can set the account by clicking Execution Account to get to the Execution Account page. You need to select Specify An Execution Account, provide a user name and password, and then confirm the password before clicking OK (it doesn’t verify that the password is correct, so make sure that it’s valid and not just matching). If you are building out more than one Reporting Services application, you will need to make sure that all the Execution Accounts are the same on all the service applications.

Configuring Email Settings

The fifth link on the Manage Reporting Services Application page is E-mail Settings. This might seem confusing at first because you also set up email settings for the SharePoint farm. Email settings for Reporting Services are separate from the SharePoint farm. The Reporting Services email system can deliver reports and/or notifications through email subscriptions. Email in Reporting Services requires that you use a Simple Mail Transport Protocol (SMTP) server, so you must have access to one or set one up. You can configure the settings by following these steps:

1. Click E-mail Settings on the Manage Reporting Services Application page in Central Administration.

2. Select the Use SMTP Server check box—otherwise, you can’t enter the other values.

3. Enter the name of the SMTP server (such as smtp.contoso.com) in the Outbound SMTP Server text box (no inbound traffic is allowed).

4. In the From Address text box, enter an email address. This doesn’t have to be valid or monitored, but you might want to use a valid email address for replies.

5. Click OK to save settings.

Provisioning subscriptions and alerts

The Provision Subscriptions And Alerts link is the same one shown when the Reporting Services service application was created. If you want to make changes or didn’t go through the provisioning right after creating the service application, you can us this link to perform that task.

Monitoring Resources

Reporting Services should be ready to use at this point. When users start creating and deploying reports, you should monitor the resources consumed so that you can modify the settings and/or topology to meet your organization’s demands.

More Info: Managing a Reporting Services service application

See http://technet.microsoft.com/en-us/library/gg492284.aspx for more information on how to manage a Reporting Services service application.

You can use the powerful PowerPivot tool for data mash-ups and data exploration. PowerPivot can be used to explore millions or even billions of rows of data. SharePoint has taken this powerful tool and made it accessible through its service application infrastructure.

In general, the users of PowerPivot won’t be your typical end users but, depending on the types of operations they are performing, they can end up use many resources. As a result, you must plan out what servers will provide these resources, who will use them, and what the settings will be on the service application.

PowerPivot doesn’t come with SharePoint Server 2013—at least, not in the initial release. You must download and install it, or find the latest version of the software to install.

After you download the PowerPivot installation file, you can install it on a SharePoint server on your farm. You need to be a local administrator as well as a member of the SharePoint Farm Administrators group to completely install PowerPivot. The following items are installed on the server when you install the installation package:

As soon as the PowerPivot service application is installed and configured, users can start using it. SharePoint shows that a new site template can be used for sites dedicated to PowerPivot functionality. Also, a feature is available on the site collection level that enables PowerPivot functionality on any site collection. Because PowerPivot is a specialized tool that’s typically used only by a small group of users, dedicating a site collection to those users is best so that PowerPivot is easier to manage.

Creating the PowerPivot service application

In the list of tasks that exist in PowerPivot Configuration Tool, notice the task called Create PowerPivot Service Application. This task creates the PowerPivot Service Application as part of the configuration. (You can also choose to create the PowerPivot Service Application at a later time.) If you do want to create the service application with the tool, you should click the task so you can verify and/or change the values. Clicking the Create PowerPivot Service Application task should display a screen similar to Figure 5-12.

Figure 5-12. Create PowerPivot Service Application task pane

You should change the values in the Create PowerPivot Service Application task pane depending on your needs. The name in the Database Name field actually has a GUID in it, but that part is hidden because the name is so long. If you’re using scripting or multiple PowerPivot service applications, you should modify the name to make it easier to type and distinguish. The database server doesn’t have to be on the SharePoint farm; it can be any PowerPivot-capable database that the default account has access to.

Exam Tip

Because PowerPivot isn’t a widely used SharePoint feature, it’s an easy one to overlook when studying for the exam. This is especially true because it has to be downloaded, installed, and configured. You should at least be aware of what’s required to install it as well as what the configuration tool can do.

You later might want to do (or have already done) several other tasks rather than have the configuration tool do them for you, such as configuring the Secure Store and Excel Services. If you’re connecting to an existing farm, more than likely these already exist and you don’t need to have them created.

More Info: Configuring or repairing PowerPivot

See http://technet.microsoft.com/en-us/library/jj820150.aspx#bkmk_steps for more information on how to configure or repair PowerPivot for SharePoint 2013 using the PowerPivot Configuration Tool.

You also can create the SQL Server PowerPivot service application within Central Administration. The SQL Server PowerPivot System service should also be running on the server on which the configuration tool was run. If you want the service to run on other servers, you should run the configuration tool on those servers and choose only the task that installs the service (Configure Local Service Instance). Creating the service application can be done in Central Administration by following these steps:

1. Navigate to Central Administration as a farm administrator and click Manage Service Applications in the Application Management section.

2. Click the New icon and select SQL Server PowerPivot Service Application.

3. Enter a name for the PowerPivot service application (such as PowerPivot Service Application) in the Name text box.

4. Create a new application pool or select an existing one in the Application Pool section.

5. In the PowerPivot Service Application Database section, enter the name of the database server to be used in the Database Server text box and a database name in the Database Name text box. The database doesn’t have to be the same one used for the SharePoint farm.

6. In the same section, select the authentication method used to connect to the database server and credentials, if necessary.

7. If you want this service application to be added to the default proxy group, leave the check box selected in the Default section and click OK (if this is the first PowerPivot service application on the SharePoint farm, you need to add the PowerPivot service application to the default proxy for the PowerPivot Management Dashboard to work properly).

Chapter 4 covers how to set up and configure Excel Services, but this section focuses on the data models created in Excel 2013. With Excel Services, you can specify one or more instances of Microsoft SQL Server 2012 SP1 to use for processing these data models. Excel Services can use Analysis Services to work with the data models; in fact, if you use Excel workbooks that store imported data in multiple tables, you need to have Analysis Services to be able to interact with the data in SharePoint. An Analysis Service instance doesn’t have to be on the same SQL Server instance as the SharePoint farm, but it does have to be on the same network and in the same domain. If the load on your Analysis Services instance becomes too great to meet the demands of your users, you can add more servers as needed.

You configure the data model settings inside the context of the Excel Services service application. The settings allow you to register one or more servers to be used for Analysis Services. Follow these steps to register a SQL Server instance to the data model settings:

After you add the Analysis Services server, you have only two options for further configuration of the item you just added. You can edit the server name and/or description, or you can unregister the Analysis Services server. These tasks can also be done from the Excel Services Application Data Model page.

The Power View tool can be used for interactive exploration of data. It provides a visual way to explore large sets of data, using various different charts and graphs. You even can connect Bing maps to data, giving users a way to map out their data by region (such as sales data per state).

Power View is installed as part of the Reporting Services add-on for SharePoint found in Microsoft SQL Server 2012 SP1 (or greater). So when you installed Reporting Services for SharePoint, you also installed the capability to use Power View. Power View reports can be created from PowerPivot workbooks or tabular data in SQL Server 2012 Analysis Services.

Power View requires that Analysis Services be installed in Tabular mode when you are installing an instance of SQL Server. If you’ve already installed Analysis Services in Multidimensional and Data Mining mode, you need to install another instance of SQL Server or change the mode to be unsupported. (You also could remove SQL Server and reinstall it, but that might not be feasible.) To install Analysis Services in Tabular mode, follow these steps when you are installing an instance of SQL Server:

After you ensure that SharePoint has access to Analysis Services in Tabular mode, ensure that Power View is working with Analysis Services. To do this, Analysis Services needs to have a data model in it to report on. You can do this by following these steps:

You and your users should be able to use Power View at this point. You might see the following error when you try to create the BI Semantic Model Connection:

Could not load type 'Microsoft.AnalysisServices.Sharepoint.Integration.ASLinkFilePage'

This error probably means that the PowerPivot farm solution hasn’t been deployed on the web application on which the PowerPivot site (or site collection that has the PowerPivot feature installed) resides. You can solve this issue by following these steps:

If you still have issues, you need to do some troubleshooting. Getting to this point involves many steps and configurations. In some cases, redoing steps might be easier than trying to fix them. Installing Power View seems to involve many steps, but it will be worth it in the end and your power users will have a great set of tools to do some outstanding data analysis.

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.

Microsoft Project Server 2013 is installed as part of SharePoint. Several versions ago, Project Server didn’t even know that SharePoint existed, but gradually it became more integrated with SharePoint until Project Server 2010, when it became a service application that ran on the SharePoint infrastructure. Although it’s not completely integrated—Project Server has its own security structure in addition to the one provided by SharePoint—Project Server can leverage the power of SharePoint for document management and project storage and allow for users to interact with projects through a browser interface.

You can use a client-side program called Project Professional to open and work with projects from a local computer or from a SharePoint server. Project files can be saved onto a SharePoint farm with or without Project Server being installed. Conceptually, this can be thought of in the same way as how other products with client-side programs (such as Word, Excel, and PowerPoint) work with SharePoint. You can use Project Server to deliver and receive project-related information without end users having to purchase a copy of Project Professional for their client machine, potentially saving your organization a considerable amount of money. Project Server doesn’t come with the SharePoint Server software, but it can be downloaded for evaluation (and eventual purchase, if desired) so that you can prepare for the exam.

Creating a Project Server web app

You are almost ready to start using Project Server, but you still need to create a Project Server web app in a new site collection or within an existing site collection. Creating the web app within its own site collection (and its own content database) is probably a good idea for the purposes of management and disaster recovery. Project Server is a complex program with data that changes frequently. The odds of having to recover data are much higher with this type of data than your typical document management data. Isolating the Project Server to its own site collection and content database greatly speeds up the recovery process.

Users of the Project Server web app need read permissions to the site collection that contains the web app. To create a site collection to be used by the Project Server web app, follow these steps:

1. Create a site collection for the Project Server web app. Project Server doesn’t require a certain template because the team site template will work fine.

2. Navigate to the site collection that you created and click Share.

3. On the Share page, click Show Options and choose the Visitors group (<site> Visitors [Read]) from the Select A Group Or Permission Level drop-down list.

4. Type Everyone in the Enter Names Or Email Addresses text box (or the user group that you want to have access to the underlying Project Server data).

5. Click Share.

You are finally ready to create a Project Server web app. That you create a new content database for the Project Server web app site and the associated workspaces is highly recommended. For this to happen, you need to create the site collection during a time when other users aren’t trying to create sites within the web application. Then, you need to perform the following steps (if the web application houses only the Project Server web app and the top-level site collection, you can have both site collections in the same content database):

1. Lock down the existing content databases (set content database to Offline).

2. Create a new content database for the web application hosting the Project Server web app.

3. Create the Project Server web app.

4. Lock down the content database created for the Project Server web app.

5. Unlock the other content databases for the web application.

Creating the actual Project Server web app can be done in Central Administration by following these steps:

1. Navigate to Central Administration as a farm administrator.

2. Click Manage Service Applications in the Application Management section.

3. Select the Project Server Service Application from the list of service applications to open the Manage Project Web Apps page, as shown in Figure 5-16.

   

   Figure 5-16. Manage Project Web Apps page

4. Click Create Project Web App Instance.

5. In the Web Application section, select the web application (the one where you created the site collection for this web app) where you want the web app instance to reside from the Web Application drop-down list.

6. Enter the path from the root site. (You can leave it as PWA if installing at the root.)

7. Select a language from the Select A Language drop-down list (pulled from the installed language packs) for the user interface.

8. Enter an administrator account in the Administrator Account text box. This user is who initially handles setting up permissions for the site.

9. Enter a database server and project web app database name in the Database Settings section. The database doesn’t have to be on the same SQL Server instance where the SharePoint farm is installed, but you can experience reduced performance if it’s not.

10. In the Site Quota section, enter the values (in megabytes) for the Quota For SharePoint Content and the Quota Warning.

11. Click OK. You are returned to the Manage Project Web Apps page, where the status displays Waiting For Resources. Wait until the status shown says Provisioned. It might take a while (a few minutes usually), depending on the resources available. If you don’t have enough resources (like low on memory), the process will fail, but it can be started again after you correct the resource issue.

More Info: Deploying a Project Web App with a new site collection

See http://technet.microsoft.com/en-us/library/ee662105.aspx for more information on how to deploy a Project web app with a new site collection.

You can also create a Project Server web app in an existing site collection for relatively small projects. In this case, the Project Server web app site would be part of the existing site collections content database, which should factor into any performance and disaster recovery considerations. The steps involved with this process are straightforward:

1. Enable the site collection feature Project Web App.

2. Create a site using the Project Web App site template.

After creation, the site is ready to use either through the browser or with the Project Professional 2013 client application, as long as users have access to it.

More Info: Deploying a Project web app in an existing site collection

See http://technet.microsoft.com/en-us/library/jj200304.aspx for more information about how to deploy a Project web app in an existing site collection.

After you create your project web app site, you can navigate to it and verify that it was created correctly. It should appear as it does in Figure 5-17. You should also verify that users who need to use the site can get to it; they have to have at least read permissions to the site.

Figure 5-17. Project Server web app site home page

From the Project web app, users can create or import projects and do all the work on the project right from the browser. This eliminates the need for having the Project Professional client application work on projects, but some licensing issues exist. Project Server 2013 is licensed separately from SharePoint Server 2013, and you need to determine how many licenses you need for your organization before allowing users access to the Project web apps. Typically, Project Server 2013 has one license for itself and then additional client-access licenses (CALs) for each user who accesses the Project Server data, either directly or indirectly.

Exam Tip

That you need to install Project Server on all SharePoint servers before you run the SharePoint 2013 Products Configuration Wizard is a prime example of a question that will lend itself to one of the “put-the-steps-in-order” questions. Note that some documentation mentions that Project Server is needed only on the app servers, but it actually needs to be installed on the WFEs also.

SharePoint 2013 can be used for eDiscovery both for SharePoint content as well as content in Microsoft Exchange. It can query emails, put holds on them, and export their content as part of the overall eDiscovery process. The process of enabling SharePoint to be able to perform these functions takes configuration on both the SharePoint farm and the Exchange farm. Chapter 2, covered how to configure an eDiscovery center in some detail, but only briefly covered the steps involved on the Exchange server. This objective covers the Exchange portion in more detail.

Communication between SharePoint and Exchange requires that the two systems trust each other. This trust needs to be established on each system separately. SharePoint trusts the Exchange server by making it a security token issuer and granting the Exchange service principal full control to SharePoint site subscription. You can make an Exchange farm a security token issuer by logging onto a SharePoint server and running the following PowerShell command in the SharePoint 2013 Management Shell as a farm administrator, where <exchange server> is the Exchange 2013 server name (or FQDN):

New-SPTrustedSecurityTokenIssuer -Name Exchange -MetadataEndPoint https://<exchange
server>/autodiscover/metadata/json/1

While you are still in the Management Shell, you can grant the Exchange service principal full control to SharePoint site subscription by running the following PowerShell commands, where <sharepoint server> is the server on which you are running the commands:

$exch=Get-SPTrustedSecurityTokenIssuer "Exchange"
$app=Get-SPAppPrincipal -Site http://<sharepoint server> -NameIdentifier $exch.NameId
$site=Get-SPSite http://<sharepoint server>
Set-SPAppPrincipalPermission -AppPrincipal $app -Site $site.RootWeb -Scope
sitesubscription -Right fullcontrol -EnableApplyOnlyPolicy

Configuration with regards to server trust is complete on the SharePoint server at this point; configuring the Exchange server is next. Typically, the administrator accounts on the SharePoint farm aren’t administrators on the Exchange farm—nor should they be. You need to make sure that the account configuring the trust on the Exchange server has the Organization Management permission to perform the necessary steps. You can use the following PowerShell command on the Exchange 2013 server to provide the necessary trust, where <sharepoint server> is a server on the SharePoint farm or the FQDN of the server:

cd c:'Program Files'Microsoft'Exchange Server'V15Scripts
.Configure-EnterprisePartnerApplication.ps1 -AuthMetadataUrl "http://<sharepoint
server>/15/_layouts/metadata/json/1" -ApplicationType SharePoint

This script works as long as Exchange is installed on the C drive; otherwise, point to the where it is installed. The preceding command is a script that relies on the PowerShell command New-AuthServer to specify a new trusted server.

Any user who will perform eDiscovery on Exchange mailboxes needs the appropriate permissions on the Exchange server. The needed permissions are provided by adding the SharePoint users performing In-place eDiscovery to the Discovery Management role group on the Exchange 2013 server.

By default, nobody is part of the Discovery Management role group. You can add users to the Discovery Management role group via the Exchange Administration Center by following these steps:

At this point, you have configured users for eDiscovery. As soon as the eDiscovery process is complete, you should remove all users from the Discovery Management role group. The elevated permissions represent a security risk that should be minimized as soon as possible.

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 are assigned to help facilitate the migration of a farm solution. Because you need to make it available to both the SharePoint 2010 mode and the SharePoint 2013 mode, you need to plan out how you will install and potentially upgrade it.

Because the SharePoint 2010 mode has no idea about the SharePoint 2013 features, you can just go ahead and install the farm solution as usual on the SharePoint 2013 farm. It defaults to the 14 folder and is available for use without any modification.

Because you want the SharePoint 2013 mode users to have access to SharePoint 2013 features, you need to modify the code for the farm solution or potentially convert it into a SharePoint app. The main issue with trying to convert the farm solution into a SharePoint app is that it’s using server-side code, and apps can’t use that. Unless the functionality of the solution can be done with server-side code, you are stuck with a farm solution and because they are still fully supported in SharePoint 2013, you will be fine for the next version of SharePoint.

Assuming that you are sticking with a farm solution, you should rebuild the solution and change the target SharePoint version to 15.0 so that when you deploy the solution, it will go into the 15 folder and not overwrite the SharePoint 2010 mode. You could force it into the 15 folder by using the CompatibiltyFolder property, but you should go ahead and change the target with Visual Studio. You then can add features specific to SharePoint 2013 to the farm solution without worry of overwriting the old SharePoint 2010 mode version. Even if the SharePoint 2013 features aren’t added right away, you should at least rebuild the solution with the updated target. Because you aren’t planning to keep the SharePoint 2010 mode version updated, this will mark the separation of the two farm solutions going forward.

In this thought objective, you have to provide PowerPivot for SharePoint to the data analyst team without spending any money on hardware or software. PowerPivot for SharePoint is a free download but requires SQL Server 2012 SP1; however, the SharePoint Server is running on SQL Server 2008 R2. Depending on the licensing, which was not specified, it can cost money to upgrade the database and in any case would cause a major disruption to services if SharePoint is heavily used.

Fortunately you could install the components necessary using the SQL Server 2012 SP1 Express edition on one of the servers in the SharePoint farm. This server would run the PowerPivot service as well as be the server where the PowerPivot configuration tool is run. You would still need a full version of SQL Server 2012 SP1 to host the PowerPivot databases, though. The PowerPivot service application can use a separate database than the one SharePoint is installed on, so this would solve your problem. Although performance won’t be quite as good from a connection standpoint, you will gain some benefit from balancing the overall SharePoint load across two database servers. After configuration, you should monitor the server running the PowerPivot service to make sure that it’s not being overtaxed. If it is, you might consider removing services from that server and/or configuring the PowerPivot settings.

In this thought experiment, you were asked to add Project Server 2013 functionality to the SharePoint 2013 farm and create a Project Server web app at http://www.contoso.com/pwa. Because you don’t have Project Server 2013 installed, that’s the first thing you need to take care of. You need to install Project Server on the two WFEs and the application server (but don’t run the SharePoint 2013 Products Configuration Wizard at the end of the setup). You don’t need to install Project Server on the database server because it’s not running SharePoint.

After you install Project Server on each SharePoint server, you need to go back and run the SharePoint 2013 Products Configuration Wizard on each of the SharePoint Servers one at a time, waiting until one server is completely done before starting on another. You should now start the Project Server Application Service and create a Project Server service application. You are restricted by the path you were instructed to use, so you could activate the Project Server site collection feature and then create a site using the Project Server site template at http://www.contoso.com/pwa. You could also go to the Project Server service application and create a Project Server web app from the Manage Project Web Apps page. This would create a site collection at http://www.contoso.com/pwa and allow for designating a database for the Project Server content as well as allowing you to set quotas specifically for the Project Server web app site. This has the additional benefit of being easier to back up and restore, greatly increasing the speed of recovery in case of a disaster. It also helps isolate issues for troubleshooting, should the need arise.