Nielsen c74.tex V4 - 07/21/2009 4:10pm Page 1562 Part X Business Intelligence TABLE 74-1 Reporting Services Project Deployment Properties Property Description OverwriteDataSources Set this to True if you want to overwrite data sources on the report server with data sources in the report project. The default value is False, which prevents data sources from being overwritten. This is helpful if the data source used for development is different from the data source used on the report server. Note this does not prevent the initial deployment of a data source, only the subsequent overwriting. TargetDataSourceFolder This is the path of the folder to which you wish to deploy shared data sources. Using this parameter enables the definition of a common data source that can be deployed to a common location and used by reports across multiple folders (or projects in development). Using a common shared connection minimizes administration efforts for the data source object. Leave this property blank to deploy the shared data source(s) to the folder specified in the TargetReportFolder property (not recommended). TargetReportFolder This is the path of the folder to which you wish to deploy reports. In BIDS, you m ust create a project for each folder (or subfolder) to which you wish to deploy reports. For example, to simplify deploying reports to two folders named Sales and Customers, set up two Reporting Services projects in Visual Studio and specify the respective folder name in the TargetReportFolder property. Then move the reports between the projects to control their deployment destination. It is also possible to use the TargetReportFolder variable to deploy to subfolders on the report server. For example, setting this value to Sales/Regional would create a nice home for your regional sales reports. TargetServerURL This is the URL of the report server you wish to deploy to. The default location of your local report server is http://localhost /ReportServer. If you named the instance SQL08, the local report server would be http://localhost/ReportServer$SQL08. This method of deploying objects to the report server is convenient when you want to update only selected objects on the report server, rather than all objects in the project. Deploying a Reporting Services project To deploy all objects in the Reporting Services project, ensure that the project deployment prop- erties are correctly configured, and then right-click on the project and select Deploy. Note that the OverwriteDataSources project property can be used to prevent overwriting data source objects. 1562 www.getcoolebook.com Nielsen c74.tex V4 - 07/21/2009 4:10pm Page 1563 Administering Reporting Services 74 This is an important feature because the data source for your reports on the report server will often require different configuration than the data source used for report development. Deploying reports using the Report Manager While BIDS provides an easy way to deploy reports to the report server, it is not required for report deployment. It is possible to deploy and configure individual Reporting Services objects using the Report Manager. The Report Manager includes features that enable the creation of new folders and data sources, and it provides the capability to upload and update report definitions (.rdl files), report data sources (.rds files), and any other file type you wish to make available on the report server (such as a PDF, Word document, Power Point presentation, Excel file, etc.). To deploy a report using the Report Manager, follow these steps: 1. Open the Report Manager application in a web browser. The default location for the Report Manager is http://localhost/reports. 2. Navigate to the folder to which you want to deploy the report. 3. Click the Upload File button. 4. Enter the path to the file or use the Browse button to find the file. 5. Enter the report name. 6. If you want to overwrite an existing report with the same name, check the option to ‘‘Overwrite item’’ if it exists. 7. Click the OK button to upload the file and return to the contents of the folder. The new report now appears in the list and is marked as New to grab the user’s attention. It’s a good idea to execute the report and verify that the data source is valid. You may need to use the Data Sources link on the Properties tab of the report to either select a shared data source or specify a custom data source for the report. You should also review the other links available on the Properties tab to set parameter defaults and configure report execution, history, and security settings. Deploying reports programmatically using the Reporting Services Web Service The Reporting Services Web Service exposes methods to deploy reports and enables custom applications to be written to perform such tasks. Remember that the Report Manager is an ASP.NET user interface that leverages the Reporting Services Web Service to manage the report server. All functionality avail- able in the Report Manager is available for your application development pleasure using the Reporting Services Web Service. To begin developing an application that will use the Reporting Services Web Service, create a project in Visual Studio and add a web reference to the Reporting Services Web Service. The default location of the Web Service on the local machine is http://localhost/reportserver /reportservice2006.asmx . After adding this web reference, you will have access to classes that enable your custom application to perform any task on the report server, including deploying and executing reports. The ReportingService class on the Web Service contains methods that enable the creation (and deletion) of folders, reports, data sources, schedules, and subscriptions, along with many 1563 www.getcoolebook.com Nielsen c74.tex V4 - 07/21/2009 4:10pm Page 1564 Part X Business Intelligence other operations on the report server. It also contains methods to render reports in any of the formats summarized in Table 74-6, later in the chapter. An alternative to a full-blown custom application is using the rs.exe utility. This utility provides methods for scripting report deployment tasks; and while it lacks some of the flexibility of the custom application option, it can be very effective for specific deployments. Configuring Reporting Services Using Management Studio SQL Server Management Studio (SSMS) has limited functionality in Reporting Services 2008, but it excels at configuring the basic server options and managing role definitions. While many of the operations described in this section are also possible from within the Report Manager application, SSMS has more options, and interactions are simpler within that familiar interface. For background on working in SQL Server Management Studio, see Chapter 6, ‘‘Using Man- agement Studio.’’ Configuring Reporting Services server properties Access server properties by connecting a Reporting Services server via the Object Explorer in SSMS. Once connected, right-click on the server and choose Properties. The resulting Server Properties dialog is shown in Figure 74-3. Use Report Manager for all content-related management and permission assignments, and use SQL Server Management Studio for server properties, role definitions, and shared schedules. The Reporting Services Configuration Manager is similar in function to its 2005 counterpart, setting service properties such as execution account, URL, and database connections, but its function has been streamlined and adapted to the 2008 architecture. The following sections describe the more commonly adjusted server properties. General By default, the option to enable My Reports is turned off. Turning this feature on enables users to manage a personal folder named My Reports, where they can publish their own reports, create linked reports, and manage their own content. Each user has his or her own My Reports folder, similar to the My Documents folder in Windows. Reporting Services contains a default role named My Reports to provide appropriate security access for this folder. Later in the chapter you’ll see how to customize roles and create new roles, but note that you can specify the role applied to the My Reports folder. Enabling the My Reports option provides a location where users can save the reports they build using the Report Builder. This tool enables users to create their own reports based on predefined data models. Configuring report execution settings The Execution tab (refer to Figure 74-3) enables you to set the default report execution timeout for Reporting Services. The default server limit is set to 1,800 seconds (30 minutes). Alternately, choose the 1564 www.getcoolebook.com Nielsen c74.tex V4 - 07/21/2009 4:10pm Page 1565 Administering Reporting Services 74 ‘‘Do not timeout report execution’’ option on the same page to remove an execution timeout limit. Any policy established at the server level can be overridden for individual reports using Report Manager. FIGURE 74-3 Use the Server Properties dialog in Management Studio to administer server options. Configuring report history settings Reporting Services can retain snapshots of reports to allow rendering of those older versions. The default behavior for keeping report history can be set to either an unlimited number of snapshots or a number that you specify (the former being the default setting, which can be overridden for specific reports if necessary). To override this for a specific report, select the Properties tab on the report in Report Manager, and then select the History link. The settings here plus those on the Execution tab enable control over how snapshots are generated, stored, and used in report rendering. Limiting the number of snapshots at the site level can help ensure that the ReportServer database does not grow beyond available storage. 1565 www.getcoolebook.com Nielsen c74.tex V4 - 07/21/2009 4:10pm Page 1566 Part X Business Intelligence Security: managing roles The security model in Reporting Services leverages Active Directory to grant access to the Report Manager and to items (folders, reports, shared data sources, etc.) within the report server. Security is administered by assigning users or groups to roles. Roles contain selected tasks that enable specific actions within the Report Manager application. Two types of predefined roles and tasks exist: system- level and item-level. Most Reporting Services installations do not actually require changes to the default roles, but rather focus on managing membership in those roles via Report Manager. System-level roles System-level roles grant access to server functions that are not item-specific. Two system-level roles are created when the report server is installed: System Administrator and System User. Table 74-2 shows the tasks granted to these roles by default. To change the predefined roles or create new roles, select the ‘‘Configure System-level Role Definitions’’ link on the Site Settings page. TABLE 74-2 Default System Roles Task System Administrator System User Execute report definitions X X Generate events Manage jobs X Manage report server properties X Manage report server security X Manage roles X Manage shared schedules X View report server properties X View shared schedules X The default role definitions can be changed by expanding the System Roles folder in Object Explorer, right-clicking on the role to be changed, and selecting Properties. If necessary, additional roles can be created by right-clicking the System Roles folder and choosing New System Role. Once defined in SSMS, managing the membership of these roles is handled by the Report Manager application as described in the following section. Item-level roles Item-level roles manage permissions associated with the reports, folders, and so on stored in the report server. SSMS presents them in the Roles folder of the Object Explorer, with the same functionality (right-click the role to edit, and then right-click the folder to add) as used with system folders. Of course, the capabilities being granted differ as described in the next section. 1566 www.getcoolebook.com Nielsen c74.tex V4 - 07/21/2009 4:10pm Page 1567 Administering Reporting Services 74 Configuring Reporting Services Using Report Manager Report Manager is a web application included with Reporting Services. It provides features required to administer the report server, and features for end-users to access and execute reports. Report Manager is an ASP.NET user interface built upon the Reporting Services Web Service. The default URL for Report Manager is http://localhost/reports. Managing security Whether you are using the default role definitions or custom definitions, as described earlier, the majority of security management generally falls to assigning membership in those roles. Granting system access to users and groups By default, the BUILTIN\Administrators group is assigned the System Administrator role. Follow these steps to grant system access to additional users or Active Directory groups: 1. Start the Report Manager application by entering the appropriate URL into a browser. 2. Click the Site Settings link in the upper-right corner and then choose the Security tab. A list of current users assigned to system roles is displayed. 3. Click the New Role Assignment button on the System Role Assignments page. 4. EntertheGrouporUsername—forexample,myDomain\jdoe or myDomain \SRSAdminstrators. 5. Select one or more system roles to assign to the group or user. 6. Click the OK button to save. Best Practice I t is important to be consistent regarding your approach to granting access to the Report Manager and to items within the Report Manager. Consider your environment when choosing how to manage and assign access and whether you grant access to Active Directory groups or to individual users. If you have already taken the time to create Active Directory groups in your organization, you can most likely leverage your existing groups to administer access to your report server. For example, if you have an Active Directory g roup for accounting, you can simply create a new system role assignment for that group to grant all of the accounting members access to the report server. Perhaps you will have an Accounting folder with accounting reports to which only accounting employees should have access. When creating this folder, simply adjust the inherited role assignments to ensure that only the accounting group has access. Regardless of which strategy you choose (user vs. groups), maintain a consistent approach in order to minimize maintenance, research, and troubleshooting efforts in the future. 1567 www.getcoolebook.com Nielsen c74.tex V4 - 07/21/2009 4:10pm Page 1568 Part X Business Intelligence Item-level permissions Item-level roles are used to control the tasks available for managing folders, reports, shared data sources, models, and other resources in the Report Manager application. Table 74-3 describes the default item- level roles created when the report server is installed. SQL Server Management Studio can be used to modify or add to these roles as described in the preceding section. To access item-level roles, select the Security link on the Property tab of any item beneath the root directory in the Report Manager. Next, click either the Edit link for an existing assignment or the New Role Assignment button. Notice how this model differs from the relational permissioning model: These roles are bundles of rights that are applied to users or groups for each object, whereas the relational database role is a bundle of users which are in turn granted permissions. TABLE 74-3 Default Item-Level Roles Task Browser Content Manager My Reports Publisher Report Builder Consume reports X X Create linked reports X X X Manage all subscriptions X Manage data sources X X X Manage folders X X X Manage individual subscriptions XX X X Manage models X X Manage report history X X Manage reports X X X Manage resources X X X Set security for individual items X View data sources X X View folders X X X X View models X X X View reports X X X X View resources X X X X 1568 www.getcoolebook.com Nielsen c74.tex V4 - 07/21/2009 4:10pm Page 1569 Administering Reporting Services 74 Controlling item-level security By default, every item-level resource inherits the security settings of its parent. If the security settings for an item have not been modified (they still inherit from their parent item), then the Security page for that item contains an Edit Item Security button. After modifying the security settings (and breaking the inheritance from the parent item), the Security page for the item contains item-level access to a user or group. Best Practice O nce inheritance has been broken, it can be very complex to make broad changes to sitewide permissions. Because of this, planning ahead for the folder hierarchy can be a big win. Keep the structure simple so that permissions can be granted on a few parent folders. For complex cases, it is sometimes easier to use linked reports to provide appropriate access, rather than break inheritance. You must belong to a system role with the Set Security for Individual Items task to complete these tasks. Follow these steps: 1. Select the Security link on the Properties tab for the item for which you wish to modify security settings. 2. If the item still inherits its security settings from its parent, click the Edit Item Security button. An alert will be displayed indicating that the security is inherited, and that if you continue to edit the item’s security, you will break the inheritance. Select OK to continue. Note that you can also delete roles that were assigned to the parent. 3. Click the New Role Assignment button. 4. Enter the group or username, e.g., myDomain\accounting. 5. Select one or more roles to assign to the group or user. 6. Click the OK button to save the new role assignment. Remember that in order for users to access an item-level resource, they must also be granted system- level access (See the earlier topic ‘‘Granting System Access to Users and Groups’’). In addition, modifying an item’s security will automatically apply the security to all child items that inherit that security. To restore the inherited security for an item that has been customized, click the Revert to Parent Security button. An alert will be displayed prompting for confirmation before the security settings defined for that item are replaced by the security settings of its parent. Working with linked reports A linked report is a shortcut to an actual report. It enables configuration of the report parameters, execution, history, and security — independent of the actual report. If the report server is configured 1569 www.getcoolebook.com Nielsen c74.tex V4 - 07/21/2009 4:10pm Page 1570 Part X Business Intelligence to allow user-owned folders for publishing and running personalized reports, users can create a linked report and configure the parameter defaults to suit their specific needs. Linked reports also provide a powerful way to administer report security and limit the available param- eters by user, group, or role. For example, consider a regional sales report with an optional parameter used to execute the report for a selected region. Certain users should be able to execute the report for all regions, while other users should only be able to execute the report for their own region. You can limit access to the actual report to the users (or an Active Directory group) who should be able to view all regions, and then create a linked report for each region and limit access to the linked reports accord- ing to the user’s privileges. For each linked report, hide the region parameter and set the default value to the desired region. You could also create a folder for each region and save the linked reports in these folders. That way, security can be controlled for the folder and multiple linked reports can be saved to the folder, thereby eliminating the need to administer security on each linked report. Creating linked reports To create a linked report, select the Properties tab on the report to which you wish to create a link and select the Create Linked Report button. Name the new linked report and enter a description and location for it. Click OK to create the report. Once created, select the Properties tab on the new linked report to administer parameters, execution, history, and security. It is also possible to create subscriptions and set up history snapshots for the linked report. To simplify analysis of dependencies and management of linked reports, it’s a good idea to include the actual report name either in the name of the linked report or in the description of the linked report. This way, you can enter the actual report name in the Search criteria (see the Search feature in the header of Report Manager) to retrieve a list of all linked reports and the actual report. Leveraging the power of subscriptions The capability to subscribe to reports represents an extremely valuable feature in Reporting Services to automate report delivery. Reporting Services supports both push-and-pull paradigms for report delivery. For example, upon scheduled report execution, a subscription can send an e-mail with an attachment containing the report content (push), with the report content in the body of the e-mail (push), or with a link to the report stored on the report server (pull). Alternatively, reports can be written to a file share where users or other systems can access the report or exported data. Report subscriptions require that the SQL Server Agent service is running on the relational database hosting the ReportServer database. This service executes jobs, monitors SQL Server, fires alerts, and allows automation of some administrative tasks for the report server. Before creating a subscription, ensure that this service is started. In addition, to successfully create a report subscription, the connection credentials for the report data source must be stored. For example, setting a data source to connect using user credentials will not work for reports running as subscriptions, as there is no interactive user at the time the subscription runs. To begin creating a subscription, select the report you wish to subscribe to and click the New Sub- scription button in the report control header. Figure 74-4 shows the options available for an e-mail subscription. You can configure options for report delivery, subscription processing and scheduling, and the report parameter values. More information about each of these options is detailed in the next 1570 www.getcoolebook.com Nielsen c74.tex V4 - 07/21/2009 4:10pm Page 1571 Administering Reporting Services 74 section, which describes how to create data-driven subscriptions, which enables these options to be set using the results from a query. FIGURE 74-4 Create a report subscription to be delivered by e-mail by configuring these options. Creating a data-driven subscription A data-driven subscription enables delivery settings and report parameters to be set dynamically using the results of a query. This is an excellent way to deliver reports and to customize the content of the reports being delivered. (Note that this feature is available only in the Enterprise Edition of SQL Server.) For example, instead of creating linked reports for each region as described earlier, a data-driven sub- scription could obtain the list of recipients and their corresponding region from a data source and auto- matically generate and deliver the reports with the content appropriate to each recipient. 1571 www.getcoolebook.com . location of your local report server is http://localhost /ReportServer. If you named the instance SQL0 8, the local report server would be http://localhost/ReportServer $SQL0 8. This method of deploying. in SQL Server Management Studio, see Chapter 6, ‘‘Using Man- agement Studio.’’ Configuring Reporting Services server properties Access server properties by connecting a Reporting Services server. Services Using Management Studio SQL Server Management Studio (SSMS) has limited functionality in Reporting Services 2008, but it excels at configuring the basic server options and managing role