We are using Azure Redis Cache for the Report Server storage. Azure Redis stops the support for TLS 1.0 and 1.1 as stated in Remove TLS 1.0 and 1.1 from use with Azure Cache for Redis.

If I set Azure Redis to allow TLS 1.0 everything works fine.

If I switch the minimum TLS version in Azure to 1.2 (or 1.1 for that matter) I start to get the error:

No connection is available to service this operation: GET TRS\1\SV
   at StackExchange.Redis.ConnectionMultiplexer.ExecuteSyncImpl[T](Message message, ResultProcessor`1 processor, ServerEndPoint server)
   at StackExchange.Redis.RedisBase.ExecuteSync[T](Message message, ResultProcessor`1 processor, ServerEndPoint server)
   at StackExchange.Redis.RedisDatabase.StringGet(RedisKey key, CommandFlags flags)
   at Telerik.Reporting.Cache.StackExchangeRedis.RedisStorage.GetBytes(String key)
   at Telerik.Reporting.Services.Engine.PersistableObject.GetInt(String key)
   at Telerik.ReportServer.Engine.StorageUpgrader.UpgradeStorageVersion()
   at Telerik.ReportServer.Web.Models.ReportServerWebHost..ctor(IStorage storage)
   at Telerik.ReportServer.Web.WebApiConfig.ConfigureDependencyResolver()
   at Telerik.ReportServer.Web.WebApiConfig.Register(HttpConfiguration config)
   at System.Web.Http.GlobalConfiguration.Configure(Action`1 configurationCallback)
   at Telerik.ReportServer.Web.WebApiApplication.Application_Start()

The articles I can find all state that we should add "sslprotocols=tls12" in addition to "ssl=true" in the connection string to support TLS 1.2.  When I do this I get the error "Keyword 'sslProtocols' is not supported". 

This won't let me use Azure Redis Cache.

I suspect the issue is due to the deprecated package that you use for the Redis database connection.

For that reason, I would like it to be updated to the new one so that I may continue to use Azure Redis.

We need to send emails to specific people only when Errors occur in scheduled reports. They shouldn't receive the scheduled reports when there are no errors.

For example, there may be a new user role added for this purpose.

We recently upgraded our report server after years of operation due to various technical challenges. Our system currently manages over 250 reports and more than 100 scheduled tasks, all of which have been running for the past seven years. The backup process has become significantly delayed, as we are handling over 70GB of data, primarily composed of daily generated reports related to executed scheduled tasks. While we regularly review execution history (execution date & time) for debugging purposes, but we never use the reports of executed scheduled task for all historical records. This leads to unnecessary storage usage, which will continue to grow over time.

Manually deleting seven years' worth of historical reports across over 100 tasks is not feasible, and scripting this deletion would impact the performance of our already heavily utilized report server.

I believe the execution history is valuable for everyone for debugging purpose. However, the associated reports which takes significant amount of storage space should be kept optional. Therefore, I propose the following features:

1. During the configuration of scheduled tasks, include an option (similar to an "Enabled" checkbox) that allows users to choose whether to retain or delete the associated report for each scheduled task execution. This would only apply to reports generated for future task executions.

2. Introduce a REST API endpoint within the Scheduled Tasks framework that would facilitate the deletion of historical tasks and their associated reports.

These enhancements would greatly improve our report management and storage efficiency as we have over 10+ intensely used report servers for different businesses.

These are some feature requests which align with our goals -

• https://feedback.telerik.com/report-server/1556062-scheduled-task-execution-retention-policy
• https://feedback.telerik.com/report-server/1657734-mass-delete-all-scheduled-task-execution-history-from-the-report-server-ui

> Ability to build directories for storing reports; and allow assigning user permissions per user.
> So, Application A, will have its reports in Directory A; Application B, will have its reports in Directory B.
> It will be a plus if you support a hierarchy or sub-directories.
> It will be a plus if you add user group, to be assign by group.

Hi Team,

This feature request is to ask that a capability be added to Report Server that restricts certain administrative functionality to only be allowed on predefined subnets (e.g. adding new users, data sources, etc.).

Thank you,

Amish

Currently the Report Server appears to keep the execution history of scheduled report tasks indefinitely.  The task execution history is a very useful feature but there appears to be no way to limit the history to a certain amount of time.  For our use case it is unlikely that we will need to go further back then 1 or two months in the history and as we get months an even years of history (which includes the execution and related documents) the time needed to backup and restore the Report Server increases.  We only have about 30 scheduled reports that run each day but over a year that is 10,000+ executions that are stored and anything over a month or so old has little value to us.  I am not sure if these also have an impact on the overall performance of the Report Server or at least the Scheduler portion of the UI but that would be another reason to limit the retention.

Currently the only method to delete the executions is to either (a) do it manually via the UI (screenshot below) or (b) to write an application that deletes executions outside our retention window using the API to query and then delete them.  Method (a) is too time consuming for a person to do and (b) will require writing the application but then also monitoring it's status and keeping up with any changes in the API over time.

I would propose adding some method of allowing users to set a "retention period" for scheduled task executions.

• The retention period would ideally be able to be set globally and overridden for a particular task
• The retention period would be specified in days
• To actually remove the old executions you could create a task that runs once a day and is executed by the windows service that exists -OR- each time the task executes to run the report it can also look to see which historical executions are older then the retention period and delete them.
• The removal of the historical tasks should also delete any associated documents

Implementing this would allow for much quicker upgrades, backups, and restores of the Report Server.

Hello, 

I recently upgraded our Report Server that was hosted in IIS with an HTTPS binding but after the upgrade we were unable to communicate with the server using HTTPS. We received an invalid client id error.

We updated the bindings and everything worked. However, it would be nice if we could upgrade Report Server without changing the IIS bindings.

Thank you.

As a user utilizing the Report Server product, I need to use a single instance of it to serve two or more completely separated divisions/clients so that they do not have access to each other's assets, so that I do not have to make two different deployments of the server and support them. See https://en.wikipedia.org/wiki/Multitenancy

As a Report Server user,
I need to deliver reports to all subscribers in a single email message,
So that no person gets the email more than once if the subscriber emails are groups and a person is part of multiple groups.
This would also allow the persons to reply to all other subscribers.

Milen

In one of our Dev environments we had Telerik Report Server installed, but unfortunately whoever set it up, didn't write down the Admin Username and Password.

The SMTP server wasn't configured when starting with the Report Server, and there is no option for resetting the password.

We do have a username and password that logs in, but it doesn't have sufficient rights to make the necessary administrational.

In such scenarios, it would be helpful if there is an external tool we may use to create an admin user directly in the Storage of the Report Server. Obviously, if somebody has unlimited rights to access the Report Server storage, he/she should be authorized also to be an admin of the Report Server.

Good evening. I have a ticket number 1563975. Attached video where you can see attached information. The TRS core database does not support SSAS OLAP connection. Only local connections work. Can you add that it is centralized?

We are using database storage for the Report Server and we are monitoring the report server service.

If the database is not accessible, for example due to it being updated, the service may stay running but it will not be able to send scheduled tasks.

In this state of the service (running, but not working), no monitoring or automated restart of the service will be triggered.

Please change the state of the service from running to not running when the service is losing contact with the database

Some of my scheduled tasks generate errors in the ServiceAgent log like:

Telerik.ReportServer.ServiceAgent.exe Error: 0 : Sending an email message failed:
System.Net.Mail.SmtpException: Exceeded storage allocation. The server response was: 4.3.1 Message size exceeds fixed maximum message size
   at System.Net.Mail.DataStopCommand.CheckResponse(SmtpStatusCode statusCode, String serverResponse)
...

and

Telerik.ReportServer.ServiceAgent.exe Error: 0 : Sending an email message failed:
System.Net.Mail.SmtpException: Failure sending mail. ---> System.IO.IOException: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
   at System.Net.Sockets.NetworkStream.Write(Byte[] buffer, Int32 offset, Int32 size)
...

In these cases, the report document seems to be generated correctly, however, it is too large to be attached to an email and there aren't any emails sent to the users.

It would be helpful to have at least notifications sent to the admin that the task was executed, but the emails were not sent due to particular reasons.

Add a "Shared resources" directory to contain images and logos used by hosted reports.