Considerations for Administering Report Builder 2.0

The administrator of the report server is responsible for a number of tasks that enable and support report authors who are creating, updating, or viewing reports by using Report Builder 2.0. For example, the administrator manages the shared data sources that are used by multiple reports and the permissions that grant access to external items—items stored on the report server—such as images and subreports as well as the reports.

For more information about Reporting Services administration, see in the "Administration" section of the Reporting Services documentation in SQL Server Books Online.

As an administrator, you need to grant Report Builder 2.0 users permissions to the report server before they can access the content and functionality of the report server. In granting permissions, you should think carefully about the distinctions between private and public folders, inexperienced and experienced users, opening and modifying shared reports, and using and creating or modifying shared data sources and grant permission based on them. For example, grant permissions with lower privileges to users who need only to open shared reports in comparison to users who need to modify a shared report.

When Reporting Services is installed in native mode, you can:

  • Enable the My Reports feature to provide report authors a private folder to create and save their own reports.

  • Use the Report Builder role on public folders to allow report authors to open a copy of a shared report. They can then save a modified version to a private folder.

  • Use the Publisher role to allow more experienced users to manage reports and shared data sources in public folders. All report authors will need permission to the ExecuteReportDefinition system task, included in the System User role by default, to run a report inside Report Builder 2.0.

When Reporting Services is installed in SharePoint integrated mode, you can:

  • Use the Read permission level, granted to the Visitors group by default, to allow report authors to open a copy of a report in a public folder. They can then save the modified version of the report to a private folder or to their local file system.

  • Use the Contribute permission level, granted to the Members groups by default, to allow more experienced users to manage reports and shared data sources in public folders.

For more information about access to data sources, see Specifying Credentials for a Report Data Source (Report Builder 2.0).

For general information about permissions and creating and using roles, see the Reporting Services and Database Engine documentation in SQL Server Books Online.

When you author reports in Report Builder 2.0 and connect to an instance of SQL Server that is installed on Windows Vista or Windows Server 2008, you might encounter an access denied error when you attempt to access the report server to open or save a report. This occurs because the security feature, User Account Control (UAC), in Windows Vista and Windows Server 2008 limit the overuse of elevated permissions by removing administrator permissions when accessing applications. Because the operating system removes permissions, members of the local Administrators group run most applications as if they are using the Standard User account. These permission are insufficient and access to the report server is denied. 

However, with additional configuration you can make the report server available to Report Builder 2.0 users.

  • Add Reporting Services URLs to trusted sites. By default, Internet Explorer 7.0 on Windows Vista and Windows Server 2008 runs in Protected Mode, a feature that blocks browser requests from reaching high-level processes that run on the same computer. You can disable protected mode for the report server applications by adding them as Trusted Sites.

  • Create role assignments that grant you, the report server administrator, permission to manage content and operations without having to use the Run as administrator feature on Internet Explorer. By creating role assignments for your Windows user account, you gain access to a report server with Content Manager and System Administrator permissions through explicit role assignments that replace the predefined, built-in role assignments that Reporting Services creates for local administrators.

For more information, see the topic "How to: Configure a Report Server for Local Administration on Windows Vista and Windows Server 2008" in the Reporting Services documentation on

Reports use embedded or shared data source definitions. An embedded data source definition is included in the report definition and used only by that report; in contrast, a shared data source definition is a file that is saved on the report server and can be used by multiple reports. Shared data sources provide significant advantages over embedded data sources.

It is recommended that you use shared data sources as much as possible. They make reports and report access easier to manage, help to keep reports more secure, and can improve performance. When reports use shared data sources, there are fewer connection strings and passwords to keep current and you can manage access by using roles. You can then give users low privilege access to the role, thus keeping your reports more secure. The share data sources can improve performance because a new connection is not needed every time the report is run. Imagine a popular report that is run by hundreds of users. If the report uses a shared data source, the users will experience better performance than they would viewing the same report were it using an embedded data source.

For more information about create and publishing shared data sources to a report server, see Connecting to Your Data (Report Builder 2.0).

Community Additions