Site Settings

When setting the limit for the number of report history snapshots kept for a given report, we encountered a setting that referred to using a default value. Each time you have the opportunity to specify a schedule for an execution snapshot, a subscription, or other feature, you have an option to select a shared schedule. The report history snapshot default value, the shared schedules, and several other site-wide settings are managed on the Site Settings page.

Configuration Options and Default Values

The main Site Settings page enables you to set several default values and configuration options. This page also acts as a front end for other configuration screens. You can access the Site Settings page by clicking the Site Settings link at the top of the page. The main Site Settings page is shown in Figure 11–17.

Figure 11–17: The main Site Settings page

We begin our examination of the site settings by looking at the configuration items and default values on the main Site Settings page.

Name

The value in the Name field appears at the top of each page in the Report Manager. You can change this to the name of your company or some other phrase that can help users identify this report server.

Report History Default

The report history default setting lets you specify a default value for the maximum number of report history snapshots to keep. This can be set to a specific number or set to allow an unlimited number of snapshots. Each report utilizing report history snapshots can either specify its own maximum number or use this default value.

Report Execution Timeout

The default for Report Execution Timeout enables you to specify a default value for the maximum amount of time a report may run before it times out. This can be a specific number of seconds or set to no timeout (unlimited execution time). Each report can either specify its own timeout value or use this default value.

Note 

The report execution timeout is specified on the Execution Properties page for each report.

Report Execution Logging

The Enable Report Execution Logging option determines whether information about each report execution is placed in the execution log. The execution log this option refers to is the ExecutionLog table in the ReportServer database. This is not referring to any of the log text files created by the Report Server application. Along with turning logging off and on, you can specify how long the Report Server should keep these log entries.

Your Reporting Services installation includes a DTS package you can use to copy the contents of the ExecutionLog into a set of user-defined tables. You can then use these user-defined tables as a data source and create reports showing the activity occurring on your Report Server. The DTS package is located in

 C:\Program Files\Microsoft SQL Server\80\Tools\                                          Reporting Service\ExecutionLog

For instructions on using this DTS package, search on “Querying and Reporting on Report Execution Log Data” on www.Microsoft.com.

Additional Settings

In addition to the configuration items on the Site Settings page, you can modify the functionality of the Report Server in other ways. In Chapter 12, we look at settings that can be changed using system properties. The system properties can be set through the Reporting Services Configuration Tool and through the SetSystemProperties method of the Reporting Services web service. See Chapter 12 for more details.

My Reports

The Enable My Reports option turns on a feature giving each user their own private folder on the Report Server. When this option is enabled, a special folder called Users Folders is created in the Home folder. Only users assigned the System Administrator role can see this folder.

Caution 

You should enable the My Reports option only if you intend to use it. Getting rid of the Users Folders folder and its content once it is created is a bit tricky. If you do create the folder, and then need to delete this folder, turn off the My Reports option, go into each folder in the Users Folders folder, and give yourself Content Manager rights. Now you can delete the folders.

Folders Created Through the My Reports Option

As each user logs on for the first time after the My Reports option is enabled, a new folder is created in the Users Folders folder. This new folder has the same name as the domain and logon name of the user signing in. The new folder is mapped to a folder called My Reports.

Let’s discuss an example to make this clearer. Sally and José are two users in the Galactic domain. Shortly after the My Reports option is enabled, Sally accesses the Report Server using the Report Manager. A new folder is created in the Users Folders folder called Galactic Sally.

Sally is not assigned the System Administrator role, so she cannot see the Users Folders folder or the Galactic Sally folder inside of it. Instead, when Sally views her Home folder, she sees a folder called My Reports. Sally’s My Reports folder is a mapping to the Galactic Sally folder.

When José accesses the Report Server using the Report Manager, a new folder is created in the Users Folders folder called Galactic José. José sees a folder called My Reports in his Home folder. José’s My Reports folder is a mapping to the Galactic José folder.

José is assigned the System Administrator role. In addition to the My Reports folder, José can view the Users Folders folder. When José opens the Users Folders folder, he can see both the Galactic Sally and the Galactic José folders. In fact, José can open the Galactic Sally folder and view its contents.

Security and My Reports

Because the My Reports folder is for each user’s personal reports, the users are granted more rights in the My Reports folder than they might be granted anywhere else on the site. On the Site Settings page, you decide which security role to assign to the user in their own My Reports folder. By default, users are assigned the My Reports role in their own My Reports folder.

A user can be granted broader rights in the My Reports folder, because they are the only one using the reports in this folder. No one else is going to set up caching and report history snapshots, for example, because no one else is going to use these reports. You want to be sure to assign the user to a role that has rights to publish reports; otherwise, each user will be unable to put reports in their own My Reports folder.

When to Enable the My Report Option

The My Reports option can be useful in two situations. First, if you have a number of individuals creating ad hoc reports for their own personal use, the My Reports folder provides a convenient spot for this to take place. If you do use the My Reports folder in this manner, you want to have some policies in place to ensure that each user’s My Reports folder does not become an ad hoc dumping ground.

The second viable use of the My Reports folder is as a quality assurance (QA) testing area for report developers. The report developers can use their individual My Reports folders as a place to test a report in the server environment before it is deployed to a folder available to the users. This is convenient because the system administrator can navigate through the Users Folders folder to access the report, after it has passed QA testing, and move it to its production location. Of course, having a dedicated quality assurance server for this purpose is far better, but in situations where this is not feasible, the My Reports folder can be considered as an option.

Other Pages Accessed from the Site Settings Page

In addition to the configuration options and default values managed on the Site Settings page, the page itself serves as a menu to other pages. These pages enable you to manage the security configuration and other site-wide settings. The following is a brief discussion of each area managed from the Site Settings page.

Site-Wide Security

The Configure Site-Wide Security page lets you assign Windows users and Windows groups to system-level roles. These system-level roles provide users with the rights to view and modify settings for the Report Server, such as those found on the Site Settings page. System Administrator and System User are the two predefined system-level roles.

For more information on system-level roles and system-level tasks, see the “Security” section of Chapter 10.

Item-Level Role Definition

The Configure Item-Level Role Definitions page enables you to modify the item-level roles. The predefined item-level roles are Browser, Content Manager, Publisher, and My Reports. You can edit the tasks assigned to these roles or create new roles. If you look at this screen, you see it also includes the View Report security role we defined in Chapter 10.

Take great care before modifying predefined roles. This makes it difficult for anyone else to work with your Reporting Services installation. Rather than modifying a predefined item-level role, copy the predefined role to a new name, make your modifications to this newly created role, and then use the new role to assign rights to users and groups.

For more information on item-level roles and item-level tasks, see the “Security” section of Chapter 10.

System-Level Role Definition

The System-Level Role Definition page lets you modify the system-level roles. System Administrator and System User are the predefined system-level roles. You can edit the tasks assigned to these roles or create new roles.

Take great care before modifying predefined roles. This makes it difficult for anyone else to work with your Reporting Services installation. Rather than modifying a predefined system-level role, copy the predefined role to a new name, make your modifications to this newly created role, and then use the new role to assign rights to users and groups.

For more information on system-level roles and system-level tasks, see the “Security” section of Chapter 10.

Shared Schedules

Each time you had an option to create a schedule for a feature, such as report cache expiration or execution snapshot creation, it was accompanied by a choice to use a shared schedule. A shared schedule lets you use a single schedule definition in multiple places. A shared schedule is created using the same page used to create all the other schedules we have been looking at in this chapter.

Shared schedules are beneficial for situations where a number of events should use the same timing. For example, suppose you have ten reports that utilize execution snapshots, all pulling data from a data warehouse. That data warehouse is updated once a week. It makes sense to create one shared schedule that can be used to run the execution snapshots for all these reports.

Not only does this save the time that would otherwise be necessary to create the schedule ten times, but it also makes it easier if the timing of the data warehouse update is changed and the execution snapshot schedule must be changed. If you are using a shared schedule, you only need to make this change once, in the shared location. Without the shared schedule, you would be forced to make this change ten times.

Manage Jobs

Scheduled items in Reporting Services use the SQL Agent to handle their operation. When you create a schedule for a task, such as creating an execution snapshot, you are creating a job in the SQL Agent. When one or more of these jobs are executing, they can be managed on the Manage Jobs page. You can use the Manage Jobs page to view the status of executing jobs and to cancel a job that is not executing properly.

Note 

Jobs appear on the Manage Jobs page only when they are executing on the server. In fact, a job must be running for more than 30 seconds before it appears on this page.