Export (0) Print
Expand All

Configuring a Report Server for Report Builder Access

New: 14 April 2006

Report Builder is an ad hoc reporting tool that installs with a SQL Server 2005 Reporting Services report server. Before you can use Report Builder, you must define role assignments that grant access to it. If you upgraded Reporting Services or if the report server uses forms authentication, you might need to perform additional configuration steps to make Report Builder available to your users.

Access to Report Builder depends on the following factors:

  • Server properties that determine whether Report Builder is available on the report server.
  • Role assignments that make Report Builder available to individual users or groups.
  • Trust levels that determine whether the ClickOnce application runs in full or partial trust. For more information, see Starting Report Builder.
  • Authentication settings that determine whether the user is prompted to enter credentials.

The client computer must have the Microsoft .NET Framework 2.0 installed. The .NET Framework provides the infrastructure for running ClickOnce applications. To access Report Builder, you must use Microsoft Internet Explorer 6.0 or later.

Report Builder is enabled by default. Report server administrators have the option of disabling the Report Builder feature by setting the report server system property EnableReportDesignClientDownload to false. Setting this property will disable Report Builder downloads for that report server. To set report server system properties, you can use script. To view a sample script that sets a report server property, see Scripting Deployment and Administrative Tasks.

A new installation of Reporting Services includes predefined role definitions that you can use to make Report Builder available to users. To use Report Builder on a new installation, you must do the following:

  1. Create a role assignment under Home that includes the Report Builder role. An item-level role assignment is necessary for granting access to report models.
  2. Create a system-level role assignment that includes the System User role. A system-level role assignment is necessary for granting access to Report Builder.

You must create these role assignments for each user who requires access to Report Builder. For more information about creating role assignments, see Creating, Modifying, and Deleting Role Assignments and Role Assignments for Report Builder Access.

SQL Server 2005 provides new tasks that allow users to create models and use Report Builder. If you are upgrading an existing installation, Setup will not modify existing role definitions to include the new tasks that grant access to these features. After you upgrade your installation, you must manually update existing role definitions and role assignments to include the new tasks. For more information, see Updating Role-Based Security for Report Builder Access.

Each user who runs Report Builder also connects to the report server. The authentication provider that is used on the server determines whether the user must re-type credentials:

Authentication Connection description

Windows authentication

Users can access Report Builder using domain user accounts. The default Windows account that is defined on the client computer is passed to the ClickOnce application launcher. To the user, the connection appears seamless because he or she is not prompted to type credentials.

Forms authentication

Users must enter a login to access Report Builder, even if they already logged in to Report Manager.

The ClickOnce application launcher cannot obtain impersonated or delegated credentials from the browser, so users must re-type their credentials.

Basic authentication using a local Windows user account and Workgroup security

If the user connects through a local account, the connection to the local ClickOnce application launcher and the remote report server are handled separately. The user must enter his or her credentials twice.

To use this connection and authentication approach, you must first modify the directory security setting on the ReportBuilder folder in Microsoft Internet Information Services (IIS), as described in the next section.

How to Enable Anonymous Access on the ReportBuilder Folder

If the report server uses basic authentication to authenticate a local Windows user account, you must enable Anonymous access on the ReportBuilder folder in IIS.

By default, the ReportBuilder folder inherits the Integrated Windows authentication setting from the parent ReportServer folder. This default setting will not work if the client and server computer are in different domains (or if the client is authenticating the user locally). Users will get HTTP 401 access denied errors and ClickOnce authentication errors such as "Cannot retrieve application" rather than the connection they expect.

To enable Anonymous access, do the following:

  1. In Internet Manager, expand Web Sites, navigate to and then expand the ReportServer virtual directory.
  2. Right-click Report Builder, and then select Properties.
  3. On the Directory Security tab, in Authentication and access control, click Edit.
  4. Click Enable anonymous access, and then click OK.

When you enable Anonymous access, users will be prompted for their credentials each time they launch Report Builder, even if they have already been authenticated to Report Manager.

How to Enable Report Builder to Launch from a SharePoint Site when Using Forms Authentication

When your Reporting Services instance is integrated with a SharePoint product or technology and you use Forms authentication, you might encounter the following error when you launch Report Builder:

"Cannot Start Application. Cannot continue. The application is improperly formatted. Contact the vendor for assistance."

To workaround this issue, you must exclude the Report Builder files from requiring authentication by updating the Web.config file and enabling anonymous access.

First, update the Web.config file with the following information so that Report Builder can launch:

<location path="_vti_bin/ReportBuilder/ReportBuilder.application">

  <system.web>

    <authorization>

      <allow users="*" />

    </authorization>

  </system.web>

</location>

<location path="_vti_bin/ReportBuilder/ReportBuilder.exe.manifest">

  <system.web>

    <authorization>

      <allow users="*" />

    </authorization>

  </system.web>

</location>

<location path="_vti_bin/ReportBuilder/ReportBuilder.chm.deploy">

  <system.web>

    <authorization>

      <allow users="*" />

    </authorization>

  </system.web>

</location>

<location path="_vti_bin/ReportBuilder/ReportBuilder.exe.deploy">

  <system.web>

    <authorization>

      <allow users="*" />

    </authorization>

  </system.web>

</location>

If your deployment is in a language other than English, you must also add the following sections to your Web.config file, and replace the LCID and culture placeholders with the appropriate value for your environment:

<location path="_vti_bin/ReportBuilder/<LCID>/ReportBuilder.chm.deploy">

  <system.web>

    <authorization>

      <allow users="*" />

    </authorization>

  </system.web>

</location>

<location path="_vti_bin/ReportBuilder/<culture>/ReportBuilder.resources.dll">

  <system.web>

    <authorization>

      <allow users="*" />

    </authorization>

  </system.web>

</location>

To find the LCID and culture for your environment, look at the directory where the files are installed. By default, this directory is located at <drive>:\<Program_Files>\Common Files\Microsoft Shared\web server extensions\14\ISAPI\ReportBuilder.

Then enable anonymous access on the ReportBuilder folder in IIS so that Report Builder can connect to the SharePoint Web application. For more information, see "How to Enable Anonymous Access on the ReportBuilder Folder" in the previous section.

Updated content

Added section about how to enable Report Builder to launch from a SharePoint product or technology when using Forms authentication.

Community Additions

ADD
Show:
© 2014 Microsoft