3. • Learn how to ensure a predictable Reporting Services
deployment in your environment
• Learn about the following as relates to Reporting Services
• Backup/restore
• Security/authorization
• Scale/performance/high availability
• Upgrade
• Approach:
• Provide the technical knowledge needed to make sound decisions
• Provide lessons learned from Real Customers
30. Considerations
Using Visual Studio 2005 to Perform Load Testing on a SQL Server 2005
Reporting Services Report Server
31. One Box Deployment
Report Server
Clients
RS Server
Report Catalog
Reporting Data
Flat Files,
OLE DB,
ODBC
Clients
RSDB
SQL, AS,
DB2, Oracle,
Teradata, etc.
Clients
32. Remote Report Catalog = Higher Scalability
Report Server
SSRS
Clients
RS Server
Report Catalog
Reporting Data
Flat Files,
OLE DB,
ODBC
Clients
RSDB
SQL, AS,
DB2, Oracle,
Teradata, etc.
Clients
33. Scale-Out & High Availability Architecture
Report Server
SSRS Scale Out Deployment
Clients
RS Server 1
Report Catalog
Reporting Data
Flat Files,
OLE DB,
RSDB ODBC
NLB
Clients
RS Server 2
RSDB
SQL, AS,
DB2, Oracle,
Teradata, etc.
Clients RS Server N
34. Custom Application Tiered Architecture
Report Server
SSRS Scale Out Deployment
Clients
Custom Application Farm
RS Server RS Server 1
Report Catalog
Reporting Data
App
Flat Files,
OLE DB,
ODBC
NLB NLB
Clients
RS Server
App RS Server 2 RSDB
SQL, AS,
DB2, Oracle,
Teradata, etc.
Clients RS Server
App RS Server N
36. Scale, High Availability, and Disaster Recovery
Scaling Up Reporting Services 2008 vs. Reporting Services 2005:
Lessons Learned
Scale-out Report Servers to include a DR site
Stop/disable the Report Server services to prevent them doing work
Mirror/Log Ship Report Catalog data to the DR site
Will need to manually fail over to this database server
Database Mirroring and Log Shipping Working Together
37. SharePoint Integrated Mode
Features Supported by Reporting Services in SharePoint Integrated Mode
SQL Server Reporting Services integration with SharePoint
Products and Technologies
Configuring Reporting Services
38. SharePoint Integrated Mode
Report Server
ShaerePoint Farm
Clients
Report Catalog
Reporting Data
SSRS
Flat Files,
OLE DB,
NLB NLB ODBC
RS Server
WFE RS Server
Clients RSDB
SQL, AS,
DB2, Oracle,
Teradata, etc.
Clients
SharePoint
Content &
Configuration
RSDB
WSS DBs
39. Extranet or Internet Deployment
Custom
Application
• Firewalls throughout environment
to protect data
• Point of entry: custom application
• Point of entry: enforce access
rights
•Internet users can query read-only
data replicated and cleansed from
original data source
• Good reference: Planning for
Extranet or Internet Deployment
40.
41. Upgrading a Reporting Server Database
Considerations for Upgrading Reporting Services
RSExec Role – RSExec Role grants SSRS service permissions to access the SQL Server databases needed to store SSRS metadata. RSExec Role is created on a number of databases in SQL Server – MSDB, Master, RSDB, RSTempDB. If the role does not exist, SSRS will fail when doing certain operations. Ensure that you are able to recreate RSExec Role during Disaster Recovery. The easiest way to re-create the RSExec role is to create a new report server database using the SSRS Configuration Manager tool. When you do this, RSExec role is created on all required locations. Then you can attach your backup databases, replacing the database you just created. Following this, use the SSRS configuration manager to explicitly choose the database you attached – this may seem like duplicate work, but it is the easy way to ensure that the SSRS service has been correctly granted rights in the RSExec role. Otherwise, you can use SSMS or another tool to explicitly add the desired user/group to the RSExec role. Notes: RDLs are stored in RSDB - so if you only need the last version, you don’t need to save off previous versions. Previous versions could be stored in an content management system like Source Depot or Visual Source Safe.
Configuration FilesThe configuration files store a multitude of settings. Specific ones to think about are settings for RSDB connection information (DSN, LogonUser, LogonPassword, etc.) & URL configuration. Overlaying configuration files from one instance to another will not work. DSN and URL configuration are the most prone to breaking, but others such as InstallationID are also problematic. Best approach is to copy settings from one file to another or write a script to do so intelligently. For DSN and URL configuration, use the Reporting Services Configuration Manager tool to set these after recovering the databases. This will ensure they are correctly encrypted or stored in the OS (http.sys or IIS metabase). Symmetric KeyIf you lose Symmetric Key, you will not be able to access any reports. You can partially recover from this by Deleting Encrypted Content from the RSDB using the Reporting Services Configuration Manager or WMI. Once you do this, you will be able to access reports, but all report data source connection information will be lost. Likewise, any usernames & passwords stored in subscriptions will be lost. To avoid needing to re-enter all of the report data source connection information, backup the symmetric key and store it in a safe place. Memorize the password that protects the symmetric key.Report Data source settings include:Username, passwordConnection stringSubscription Settings can optionally include:Username, passwordCustom – any properties the delivery extension requests to be stored securely.
Security can be a daunting problem to consider. The question always comes up – “where to start?” The you should start by looking at the most ASSETS you want to protect. Then look at how users get access to those assets and what mitigations you have in place to ensure users don’t get too much access. For any reporting solution, the goal is to provide data to users. The data is your most precious asset. Figure out first how to protect the data. Every other decision you make about security in a reporting deployment will stem from protecting the data. When using Integrated Security credentials or Prompt credentials, it is easy for a malicious report author to use the user’s credentials to access an underlying data source. The malicious author has control over the SQL Statement/Query that is executed. If they choose they can run the statement under the user’s credentials which could lead to a ‘trojan report’. It is up to the SSRS administrator to ensure users are not preying on other users. You can address this by using:Shared Data Sources - to store prescribed credentials; admin controls these and can set them to be low privilege; also store connection strings meaning that reports use specific data sources rather than any data source the author choosesReview reports prior to publish or after publishing – scrutinize the use of embedded data sources to ensure there is a business purpose behind it. Deny users permission to publish reports in “official” foldersDon’t tell the report author the data source credentials of the production server For the paranoid – disable integrated authentication – See the SSRS System PropertiesNot using Kerberos delegation – without delegation, unless the user is on the local server computer, using Windows Integrated authentication doesn’t work; the request from SSRS to the data source will be an anonymous request. Does not help against the ‘prompt’ issue… By correlation, admins should be cautious about running un-trusted reports when while logged into the actual SSRS server computer; running the report from a remote client machine when Kerberos delegation is enabled avoids this problem. Use Read-only Accounts – effectively accounts that you don’t care if the password is disclosed.
Enable caching of reports – the report cache is best used for frequently run reports that DO NOT require up to the second data on every refresh. If a data latency of 5 to 15 or more minutes is OK for the user base, enabling caching can be very useful. Caching is per report parameter combination. Caching is not available for reports that have a user profile dependency or that use integrated security – if the data in the report is somehow user specific, we disable caching so users don’t get other user’s data. User profile dependency means using properties from the User!* Properties in RDL (i.e. User!UserId). Cache can be pre-populated using data driven subscriptions, null rendering extension and null delivery extension.Enable Scheduled snapshot creation – if report data is updated very infrequently, report queries take a long time to execute, or if all users need to see a single view of the data, then snapshots can significantly reduce overhead. Snapshots run once and then are available to all users with access to the report. This minimizes the number of times the queries are executed. It can also reduce the amount of time the user is waiting for the rendering since SSRS does not need to retrieve the data from the data source.At the extreme, a custom application may be needed to ensure your overall environment is not impaced. Example – One customer we talked to has a report that causes significant load on the underlying data source. 4 concurrent executions of the report cause the underlying data source to fail. Solution was to schedule report executions to avoid 4 concurrent executions. As part of their front end application to SSRS, the customer built a queuing mechanism to ensure serialize the report executions.
Monitoring RS Performance, i.e. How to know things work
Which reports are long running?Sort by ElapsedSec or RowCountReview TimeDataRetrieval, TimeProcessing, TimeRenderingIf high TimeDataRetrieval, you need to optimize data source (e.g. add indexes, hints, etc.)If high RowCount (e.g. >1000 rows):A lot of data aggregated, grouped, filtered, sorted by SSRS; have SQL do this as its faster at itA lot of details, provide aggregate reports and have them drill-through vs. manually digesting and determining patternsSubscriptions/Interactive?Sort by RequestTypeIf a lot of subscriptions, can determine the bottlenecks and stagger reportsLive Data or Snapshots?Sort by SourceIf reports can be snapshot (e.g. last week’s report), then create snapshot to avoid query execution, report processing, and report renderingBalanced?Sort by InstanceDetermine if NLB is handling request in balanced fashion Or Nodes down or not processing requestsPatterns for a reportSort by ReportPath and TimeStartE.g. expensive report (takes 5 min to run) running every 10 minHealth of ReportsSort by StatusFailures occur before (e.g. incorrect RDL) or after (e.g. subscription delivery error) report is processed Outdated information or settings (e.g. expired passwords, missing subreports, etc.)Based on this, can create data driven subscriptions:Errors > 5%Continual scale mode
A common approach to scaling Reporting Services is to scale up similar to the way we scale up SQL Server.While you can do this, the approach for scaling Reporting Services is really to scale out. The idea is that you can have multiple Report Servers that reference a remote catalog. You have multiple servers sharing the same catalog database so that way you can be sharing the state information between the all of the boxes.
A common approach to scaling Reporting Services is to scale up similar to the way we scale up SQL Server.While you can do this, the approach for scaling Reporting Services is really to scale out. The idea is that you can have multiple Report Servers that reference a remote catalog. You have multiple servers sharing the same catalog database so that way you can be sharing the state information between the all of the boxes.
Configure Affinity on the NLB – this saves processing time.A common approach to scaling Reporting Services is to scale up similar to the way we scale up SQL Server.While you can do this, the approach for scaling Reporting Services is really to scale out. The idea is that you can have multiple Report Servers that reference a remote catalog. You have multiple servers sharing the same catalog database so that way you can be sharing the state information between the all of the boxes.
A common approach to scaling Reporting Services is to scale up similar to the way we scale up SQL Server.While you can do this, the approach for scaling Reporting Services is really to scale out. The idea is that you can have multiple Report Servers that reference a remote catalog. You have multiple servers sharing the same catalog database so that way you can be sharing the state information between the all of the boxes.
Front ends connected to same cluster of databasesContent switch allows for automatic failover of SSRS servers (IP address remapping)Mirrored databases on disaster recovery site asynchronously (some metadata loss is okay)Manual failover from primary to disaster recovery siteDatabase Instance names are the same (e.g. REDMOND\\sql4, BAY\\sql4)
In SSRS 2005, adding more than 4 cores per SSRS instance does not help increase throughput on that instance. Adding memory is always beneficial to throughput.In SSRS 2008, more than 16 cores per SSRS instances does not help increase throughput on that instance. Adding memory is always beneficial throughput.SSRS supports scale-out deployments. Customers are employing virtualization to deploy more instances of SSRS on larger hardware boxes; they add Virtual Machines running SSRS nodes to a single scale-out deployment automatically based on Reporting load. This approach helps them consolidate hardware and therefore have fewer total servers to manage. Customers are reporting about a 30% decrease in throughput due to the overhead of virtualization. However, overall performance is acceptable to meet SLAs and customer are proceeding to roll these deployments into production. Customers have done this work on both Hyper-V and 3rd party virtualization solutions. In terms of server consolidation, there is no question that SSRS 2008 scales up much better than SSRS 2005. Therefore upgrading to SSRS 2008 can help you achieve your server consolidation objectives.
Hiding reports or datasources in SharePoint modeCannot do it SharePoint; confusing to users; Created a custom default view with document typesa
http://msdn.microsoft.com/en-us/library/ms159272.aspxAt the first entry point, customers often put a device that enforces security access. They tightly couple the access location of the user is trying to access with a set of static permissions. Various 3rd party and Microsoft products offer this capability; ForeFront and IAG server are examples.
Common troubleshooting issues:Backup encryption keysScenario: The report server installation is not initialized (rsReportServerNotActivated).Occurs when we point a new instance to an existing database; to initialize the instance you need to import encrypted keys to get it activatedRecall, upgrade involves schema changes:Schema upgraded automatically after setupSecurity descriptors upgraded on first use / after schemaPublished reports and compiled report snapshots are updated on first use
Configuration setting for extensions may be removed by service pack upgrades. This is being addressed. However, best to backup extensions; always best to know if extensions work/are configured correctly before upgrading.
(Talk to):Automate using rs.exe scripting utilityCheck WMI status using WMI Provider & Power ShellCheck versions of servers easily by looking at Report Server Vdir or SOAP headersCreating Shared data source ensures your server can access secure information like usernames passwords and has a solid encryption key.