Disable and enable multiple Subscriptions in PBIRS/SSRS 2017

Our Reporting Team wanted to disable all of the actual subscriptions because our production has to be stopped in case of the Coronavirus Pandemie and reports don’t show realistic data. But they want to be able to activate the same reports again later – and not all reports!

Our first “solution” to disable all of the reports was to send the reports by email
to “/dev/nul” 😉
Therefore we changed the SMTP Mailserver in the Reporting Services Configuration. Below is a link to a mini PowerShell SMTP Server “Blackhole” which we tested on the SSRS. Later I’ve found that there doesn’t need to be a SMTP Server running. Changing the entry works without any problem.

The success lasted only one day.
Then the Reporting Team needed to activate some reports again, so our solution doesn’t work anymore.

A Google Search shows up several PowerShell snippets to disable or enable simple reports via the subscription id or do this for all of the reports (Link in the notes at the end of this article). But there is no solution for a huge number of reports (~600 Reports).
BTW: Enabling and disabling Report Subscriptions only works from version 2016 and beyond!

With a litte help from my friend Claudio @ClaudioESSilva I implemented the idea of storing the subscription IDs in a sql table and using them for disabling and enabling all IDs in a loop.

<# 
Name: SSRS enable disable Reports.ps1
Author: Volker Bachmann
Date: 11.4.2020

:
Disable and Enable Reports or their subscription with a list of SubscriptionIDs

#>

Function LogWrite
{
    # simple function for logging to a file.

    Param ([string]$logstring)
   $Logfile=".\enable_disable_reports.log"

   $logstring += " ["
   $logstring += (Get-Date).toString("yyyy/MM/dd HH:mm:ss")
   $logstring += "]"

   Add-content $Logfile -value $logstring
   
}


# $URI="http://<SSRS Server>/ReportServer/ReportService2010.asmx" 
[int]$counter=0


# ############################################################################
# Disable specific Subscriptions, defined in a referenced SQL Table

<# SQL Table Definition and Load

    CREATE TABLE [dbo].[Subscriptions](
    [id] [INT] IDENTITY(1,1) NOT NULL,
    [subscription_id] [UNIQUEIDENTIFIER] NULL
    ) ON [PRIMARY]
    GO

    INSERT INTO Subscriptions (subscription_id)
    VALUES

    ('D0DD9A1C-2393-4529-9F93-85DEC5FCD42F'),
    ('A023E6B9-943E-4A53-806D-1A05A8FBE0A8'),
    ('F28A93D5-FB56-46BE-A057-5B16945728B6');

#>

[string]$serverName = '<SSRS Server>' # ServerName for the list of subscriptionIDs

# connection to the table of subscription ids
$SubscriptionList = (Invoke-SQLCmd -query "select * from [Subscriptions]" -Server $serverName )

# connection to the Reporting Server with actual credentials
$rs2010 = New-WebServiceProxy -Uri $URI -Namespace SSRS.ReportingService2010 -UseDefaultCredential;  

# create new chapter in the logfile
LogWrite  "############# Start disable ###################"

# loop through all subscription ids of the list and disable them
ForEach ($subscription in $SubscriptionList)  
{  
    # Error-handling with a try/catch 
 
try {
    $rs2010.DisableSubscription($subscription.ItemArray[1]);  
        
        write-host "disabled :"  $subscription.ItemArray[1]

        $output = "disabled : "+  $subscription.ItemArray[1]
        LogWrite  $output
    
        $counter ++ # counting the amount of successful disabled subscriptions

    }
catch {
    write-host "Error during disabling of id :"  $subscription.ItemArray[1]

    $output =  "Error during disabling of id : "+  $subscription.ItemArray[1]
    LogWrite  $output
    }    
}# End ForEach

$output =  "=> Amount of disabled Subscription IDs : " 
$output += $counter 
LogWrite  $output

# Chapter End in Log
LogWrite  "############# End disable  ###################"

This was for disabling the subscription IDs – enabling is nearly the same:

# ###################################################################
# Enable specific Subscriptions, defined in a referenced SQL Table
 
# Definition and load of the table see above.

# ServerName for the list of subscription ids
[string]$serverName = '<SSRS Server>' 

# connection to the table of subscription ids
$SubscriptionList = (Invoke-SQLCmd -query "select * from Subscriptions" -Server $serverName )

# connection to the Reporting Server with actual credentials
$rs2010 = New-WebServiceProxy -Uri $URI -Namespace SSRS.ReportingService2010 -UseDefaultCredential;  

# create new chapter in the logfile
Log-Write  "############# Start enable ###################"

# loop through all subscription ids of the list an enable them
ForEach ($subscription in $SubscriptionList)  
{  
    #try/Catch see above
try {
    $rs2010.EnableSubscription($subscription.ItemArray[1]);  

        write-host "enabled :"  $subscription.ItemArray[1]

        $output = "enabled : "+  $subscription.ItemArray[1]
        LogWrite  $output
    
        $counter ++ # count the amount of successful subscriptions
    }
    catch
    {
    write-host "Error enabling id :"  $subscription.ItemArray[1]

    $output = "Error enabling id : "+  $subscription.ItemArray[1]
    LogWrite  $output
    }
} # End ForEach

$output =  "=> Amount of enabled Subscription IDs : "
$output += $counter 
LogWrite $output

# End in Log
LogWrite  "############# End enable ###################"

These two snippets work for me.
Disabling Subscriptions brings up some Errors for me when:

  • Owner of the Subscription is not valid any more -> change Owner
  • Subscription is not a report – it was a Power BI or other subscription
  • In the subscription was an End date set – than the disable didn’t work for me.

Any comments, additions?

Thanks for Reading,
Volker

Notes: Links to documentation from Microsoft:

SMTP Blackhole (German only): https://www.msxfaq.de/tools/sonstige/smtp_blackhole.htm 

Migration SSRS 2008R2 -> 2016 – Renderformat für Excel hat sich geändert

Migration SSRS 2008R2 -> 2016 – Renderformat für Excel hat sich geändert

Bei der Migration unseres SQL Server Reporting Servers von 2008 R2 auf 2016 ergab sich gerade die Schwierigkeit, dass die zu versenden Excel Dateianhänge nicht erstellt werden können.
Die Reports und die Abos bleiben grundsätzlich erhalten wenn die Datenbanken ReportServer und ReportServerTempDB einfach mit umgezogen werden. Die Jobs werden nach Aktivierung des alten Berichtsserver-Schlüssels automatisch wieder erstellt.

Hintergrund der Fehlermeldung zu Excel ist dann das Renderformat. Das stand bei 2008R2 noch auf Excel 2003. Das Format gibt es nun aber nicht mehr.
Das bedeutet es muss in allen Reportabos das Format des Dateianhangs umgestellt werden.

Entweder manuell für jeden Report einzeln oder für alle Reports gleichzeitig per Skript.
Die Basis des Skripts ist für die Änderung von Email Adressen der Empfängern innerhalb der Reports (Quelle s.u.).
Ich habe das für mich angepasst so dass nun das Renderformat geändert werden kann.
Es muss dann anstatt EXCEL einfach EXCELOPENXML heißen:

DECLARE  @OldParameter      VARCHAR(100) = '<Value>EXCEL</Value>'
DECLARE  @NewParameter    VARCHAR(100) ='<Value>EXCELOPENXML</Value>'

BEGIN TRANSACTION
      UPDATE Subscriptions
            SET ExtensionSettings = CONVERT(NTEXT,REPLACE(CONVERT(VARCHAR(MAX),ExtensionSettings),@OldParameter,@NewParameter))
        FROM ReportServer.dbo.Subscriptions
        WHERE CONVERT(VARCHAR(MAX),ExtensionSettings) LIKE '%' + CONVERT(VARCHAR(100),@OldParameter) + '%'
COMMIT TRANSACTION

So hat es bei uns geklappt.

Danke fürs Lesen,
Volker

Quelle: http://www.sqlservercentral.com/blogs/briankmcdonald/2010/07/19/updating-email-addresses-in-ssrs-subscriptions/

Optimierung Reporting Server MS SQL 2008 R2 Teil 2

Nach der Optimierung des Reporting Servers aus Teil 1 https://blog.volkerbachmann.de/2015/01/31/optimierung-reporting-server/ war es nur wenige Monate ruhig um den Reporting Server.
Die Anzahl der Reports steigt nahezu täglich und die Reports können nicht weit genug auseinander gezogen werden damit diese sich nicht in die Quere kommen.

Deshalb haben wir die Analyse mit der Unterstützung von Dell – als Lieferant des SQL Servers – noch einmal durchgeführt.

Ausgangslage: Reports brauchen bis zu 2 Stunden bis sie versendet werden

Analyse durch Dell mit DPack Tool
Flaschenhals:
1. Festplatten IOPS
2. RAM

Lösungsmöglichkeiten
1. Mehr IOPS zur Verfügung stellen
a. Vorhandene 6 Festplatten durch SSD ersetzen
b. Zwei SSD zusätzlich im RAID 1 und Verlagerung der meist frequentierten DBs auf diese SSD
c. Eine oder zwei SSD als CacheCade (erweiterter Cache des RAID Controllers) einrichten
2. Mehr Arbeitsspeicher zur Verfügung stellen
a. Zusätzlicher Speicher inkl. Enterprise Lizenz und ggf. Neuinstallation des Servers.

Das waren die Lösungsansätze bezüglich Hardware.

Weitere Möglichkeit:
3. Optimierung der Abfragen mit Unterstützung eines SQL Server Spezialisten

Kosten für die Umbauten:Kosten Optimierung Reporting Server 2008 R2

Durchgeführte Maßnahmen

1. Arbeitsspeicher +32GB / Windows Server Enterprise Edition
2. Eine SSD im RAID 0 für ReportServerTempDB
3. Optimierungen der Reports
durch Snapshot Technologie

Der Performance Monitor zeigt die Antwortzeiten für die TempDB Dateien sowie die 100% Aktivität der entsprechenden Festplatten im RAID 10.

Vor dem Umbau:

Performance Monitor vorher

Nach dem Umbau:

Performance Monitor nachher

Deutlich zu sehen ist dass die Antwortzeiten für die TempDB-Dateien (nun auf der SSD) auf “0” runter gegangen und auch die Aktivität auf der SSD (Partition S:) ist auf 3% runter gegangen ist.

Als abschließender Vergleich nun noch die Laufzeiten ausgewählter Reports: Laufzeiten der Reports im Vergleich

Ergebnis: Seit Einbau der SSD sind die Laufzeiten der Reports deutlich runter gegangen. Auch die Snapshot Technologie hat für einige Reports deutliche Verbesserungen gebracht.

Der Einbau des Arbeitsspeichers alleine hat nicht dafür gesorgt dass die Reports schneller ausgeliefert werden konnten, hat aber dafür gesorgt, dass der Server im Ganzen nicht mehr so eng an den Grenzen des vorhandenen Arbeitsspeichers arbeitet, sondern noch ein wenig Luft hat.

Bisher ist das Ergebnis soweit ausreichend, dass keine weiteren Maßnahmen mehr notwendig sind.

Weitere Möglichkeiten wären:

  1. Umsetzung der Snapshot Techniken für weitere Reports
    2. Verlagerung weiterer (temporärer) Datenbanken auf die SSD
    1. ReportServer TempDB
    2. ReportCodes DB
    3. Sonstiges
    1. Optimierung von Abfragen, Indizes
    2. Ggf. In-Memory / Columnstore Index

Danke fürs Lesen.
Über Kommentare würde ich mich sehr freuen.

Viele Grüße
Volker