When you revert to another Report revision and don't refresh the browser page, the date of the active report in the Revisions History is different from the Report Date Modified. The user needs to refresh manually to match the dates.

The issue is demonstrated in the linked muted video.

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.

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.

HTML5 Report Viewer cannot connect to report server for .NET.

The old report server still connects us expected.

I am trying to edit an existing user, and before changing anything I receive the error message 'The email is already taken!'. This happens occasionally.

Here is a link to a video that demonstrates the problem.

In the production environment, there is no option to clear the Redis database after each redeploying/restarting of the applications (ex. k8s with many pods).

The are many reasons:

• this database can be used for other purposes, but you deprecate RedisStorage with a separate database selection
• more complex deploy/restart operations with additional steps to clear Redis
• users can use Reporting at this moment

Please add TTL option for RedisStorage in ReportServiceConfiguration

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.

On some system configurations, the setup wizard throws the following error when upgrading the Telerik Report Server from version R2 2023 SP1 to version R3 2023 SP1.

To work around the issue, one can uninstall the previous version first and install the new one afterward.  

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.

In my MSSQL database, I use SQL Server Authentication with a password that contains '^' and '<'. I connect without problems through the MSSQL Management Studio.

When I try to pass the connection string with this user, I receive an Internal Server Error and cannot set up storage with it.

Hello, 

I was on a remote web session with an engineer and we discovered that the Scheduler UI isn't saving the changed password to the database. 

The environment that I use is below. 

• Report Server is installed in an Azure Virtual Machine
  • IIS is bound to ports 443 and 83
• The SMTP Service is on RackSpace
• The storage is located in SQL Server

The steps to reproduce are as follows.

1. Change the Password
2. Save the Changes
3. Send Test
4. Receive Error output

During the Remote Web Assistance Session, we tried a Gmail SMTP server and received the same results. 

We also enabled tracing and noticed an error in the event logs which I will attach here. 

Please let me know if you need any additional information.

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

The 'report name/Shelve' path seems to be broken.

For example, when I try to preview the report in Server > Web Preview in the Standalone Designer connected to the Report Server, the browser tries to open the URL 'reportServerHost/Report/View/CategoryName/ReportName/Shelve'. However, it hangs and doesn't display anything.

Yesterday I installed the report server. Everything seemed to be working correctly. Today when I try to view a report I get this error message "Error registering the viewer with the service. An error has occurred. Incorrect value (null) deserialized. Make sure you are using CacheStorage inside single-instance application deployment only."