SharePoint-SSRS-Webpart vor Supportende

Consulting Briefing – SSRS Report Viewer Webpart in SharePoint: Supportende am 13. April 2026

1) Was passiert am 13. April 2026?

Am 13. April 2026 stellt Microsoft den Support für das „SQL Server Reporting Services (SSRS) Report Viewer“-Webpart für SharePoint ein. Übersetzt aus dem Microsoft-Sprech: keine Updates mehr, keine Fixes mehr, kein offizieller Support mehr – auch dann nicht, wenn es weh tut und man freundlich fragt.

Wichtig ist die Nuance, die in vielen Umgebungen zuerst beruhigt und später für Bauchschmerzen sorgt: Das Webpart bleibt voraussichtlich zunächst funktionsfähig, aber es ist eben „unsupported“.
Das bedeutet: Wenn irgendwann Sicherheitslücken, Browser-Änderungen, SharePoint-Patches, TLS-Anpassungen oder Reporting-Server-Updates in die Quere kommen, steht man im Regen. Und der Regen wird in IT-Projekten selten romantisch.

Microsoft empfiehlt als Alternative ausdrücklich, SSRS-Berichte per URL-Parameter einzubetten (statt per Webpart).

2) Welche Systeme sind betroffen?

Betroffen sind typischerweise SharePoint Server On-Prem-Installationen, in denen paginierte SSRS-Berichte (also die „klassischen“ Reporting-Services-Berichte, RDL/Report Server) über das Report Viewer Webpart direkt auf SharePoint-Seiten eingebettet sind. Microsoft beschreibt das Webpart genau für dieses Szenario: Berichte in SharePoint-Seiten darstellen, oft als fester Bestandteil von Teamseiten, Portalen oder Intranet-Bereichen für Controlling, Vertrieb, Produktion und IT.

In der Praxis sieht das häufig so aus:

• Eine SharePoint-Seite enthält ein Report Viewer Webpart.

• Das Webpart zeigt einen SSRS-Bericht aus einem Reporting Services Report Server (Native Mode) oder einem ähnlichen Setup an.

• Benutzer filtern Parameter (Zeitraum, Kostenstelle, Region), exportieren nach Excel/PDF oder drucken.

Nicht der Kernpunkt ist „SSRS geht weg“ – der Kernpunkt ist: diese konkrete SharePoint-Webpart-Integration wird nicht mehr gepflegt.

3) Warum das Supportende mehr ist als „wird schon laufen“

Wenn etwas „weiter funktioniert“, ist das im Betrieb oft nur die erste Phase: „Alles gut.“
Die zweite Phase: „Warum klappt es nur noch im Edge, aber nicht im Chrome?“
Die dritte Phase: „Warum blockt unser Security-Stack das plötzlich?“
Die vierte Phase: „Wer hat das eigentlich eingebaut? 2017? … Hallo?“

Microsoft sagt ausdrücklich: keine Updates nach dem Stichtag.
Das heißt: Selbst wenn die Berichte weiter rendern, steigt das Risiko, dass ein ungepatchtes Add-on zum Einfallstor wird oder zumindest zum Compliance-Problem („unsupported component in productive environment“). Das ist nicht automatisch ein sofortiger Notfall – aber ein klarer Punkt für Risikoregister und Maßnahmenplan.

4) Handlungsempfehlungen: Was Admins jetzt tun sollten

Schritt 1: Bestandsaufnahme – wo steckt das Webpart überall?

Bevor man migriert, muss man wissen, wo überhaupt betroffen ist. Klingt banal, ist aber der Teil, der gerne unterschätzt wird.

Praktisch bewährt:

• In SharePoint: Suche nach Seiten/Layouts, die das Report Viewer Webpart enthalten (je nach Version: Webpart-Typ/Assembly/Markup).

• Parallel: Befragung der Fachbereiche („Wo hängt bei euch Reporting in SharePoint?“) – ja, wirklich. Manche Seiten heißen „Teamseite Vertrieb Nord“ und sind trotzdem geschäftskritisch.

• Reporting-Server-Seite: Liste aller Reports, die typischerweise via SharePoint konsumiert werden (Zugriffslogs sind Gold wert, falls vorhanden).

Ziel: Eine Liste mit

• Seite/URL in SharePoint

• Report/URL im Report Server

• Kritikalität (hoch/mittel/niedrig)

• Besitzer/Fachbereich

• Nutzungsfrequenz

Schritt 2: Entscheidung pro Bericht – URL-Einbettung oder Power BI?

Microsoft nennt als empfohlene Alternative die Einbettung per URL-Parameter.
Das ist meist der schnellste Weg, um ohne großen Plattformwechsel wieder stabil zu sein.

Option A: URL-Einbettung (SSRS URL Access)

• Vorteil: Geringe Umstellung, SSRS bleibt SSRS.

• Vorteil: Passt gut zu On-Prem-SharePoint, wenn man dort bleiben muss.

• Nachteil: Funktionalität/Look & Feel kann anders sein als beim Webpart, je nach Seite und Einbettungscontainer.

• Nachteil: Man muss sauber testen (Parameter, Auth, Export, Print).

Option B: Migration auf Power BI (oder Power BI Report Server / paginierte Reports, je nach Lizenz/Strategie)

• Vorteil: Modernere Plattform, bessere Integration in M365-Welt (dort, wo sie genutzt wird).

• Vorteil: Langfristig meist strategisch sinnvoll, wenn ohnehin Modernisierung ansteht.

• Nachteil: Migrationsaufwand, Lizenz- und Kapazitätsfragen, Datenmodellierung, Governance.

Für SharePoint Online gibt es den etablierten Weg, Power BI-Berichte als Webpart auf modernen Seiten einzubetten – Microsoft dokumentiert das inklusive Lizenz- und Voraussetzungen.
Und wenn es um „eingebettet für Kunden/Apps“ geht, ist Power BI Embedded der Klassiker (Kapazität/App-owns-data-Szenarien) – in SharePoint Online ist das Thema „Bericht einbetten“ jedenfalls offiziell und sauber beschrieben.

Schritt 3: Sofortmaßnahme – Risiko reduzieren, ohne alles umzubauen

Falls die Migration Zeit braucht (sie braucht Zeit), dann:

• Dokumentieren: „Webpart ist ab 13.04.2026 unsupported“ als bekanntes Risiko.

• Governance: Zulassen neuer Report-Viewer-Webparts stoppen (Change-Prozess).

• Security: Monitoring/Scanner-Regeln anpassen, damit veraltete Komponenten sichtbar bleiben (nicht unsichtbar verrotten).

5) Migrationsplan, der im echten Leben überlebt

Hier ein praxistauglicher Plan in fünf Phasen – nicht zu akademisch, aber robust:

Phase 0: Kickoff und Scope (1–2 Wochen)

• Verantwortlichkeiten: IT (SharePoint/SQL), Security, Fachbereichsvertreter.

• Zielbild pro Bereich: „Quick Fix via URL“ oder „Modernisierung zu Power BI“.

• Zeitachse rückwärts vom 13. April 2026 planen.

Phase 1: Inventarisierung und Priorisierung (2–4 Wochen)

• Alle betroffenen Seiten/Reports erfassen.

• Priorisieren nach Kritikalität und Nutzung.

• „Top 20“ zuerst – denn die machen meistens 80 Prozent der Schmerzen aus.

Phase 2: Technischer Proof of Concept (2–3 Wochen)

• Für 3–5 repräsentative Berichte URL-Einbettung umsetzen (inkl. Parameter, Auth, Export).

• Parallel: 1–2 Kandidaten für Power BI evaluieren (Datenquelle, Modell, Berechtigungen).

• Ergebnis: Entscheidungsmatrix „welcher Bericht wohin“.

Die URL-Alternative ist von Microsoft ausdrücklich als empfohlener Übergang genannt – und sollte daher der erste Test sein, wenn das Ziel „schnell stabil“ lautet.

Phase 3: Migration in Wellen (6–12 Wochen, je nach Umfang)

• Welle 1: Hochkritische Berichte/Seiten.

• Welle 2: Mittlere Priorität.

• Welle 3: Rest.

Wichtig: Jede Welle endet mit einem kurzen Abnahmeprozess: „Parameter ok, Export ok, Berechtigungen ok, Benutzer ok“.

Phase 4: Schulung und Umstellung der Benutzer (laufend, aber geplant)

Benutzer haben sich an das alte Webpart gewöhnt. Selbst wenn die neue Einbettung technisch funktioniert, gibt es immer „Aber vorher war der Button da oben…“.

Schulungsbausteine (kurz und wirksam):

• „So finde ich meinen Bericht jetzt“ (neuer Link / neue Seite).

• „So setze ich Parameter“ (falls anders).

• „So exportiere ich“ (PDF/Excel).

• „Was mache ich, wenn etwas fehlt?“ (Supportweg).

Phase 5: Abschalten/Stilllegen (nach erfolgreicher Umstellung)

• Report Viewer Webpart nicht mehr verwenden, wo ersetzt.

• Altes nur noch als Archiv, falls nötig – aber nicht als produktive Lösung.

6) Kommunikationshinweise für das Management (und für das eigene Nervenkostüm)

Ein Satz, der intern gut funktioniert:

„Am 13. April 2026 endet der Support für das SSRS Report Viewer Webpart in SharePoint. Berichte laufen wahrscheinlich weiter, aber ohne Updates steigt das Sicherheits- und Betriebsrisiko. Wir migrieren planvoll, damit Reporting ohne Unterbrechung verfügbar bleibt.“

Das ist sachlich korrekt und deckt sich mit der Microsoft-Ansage: Supportende, keine Updates, Empfehlung zur URL-Einbettung, weiter funktional aber unsupported.

7) Fazit: Früh anfangen, damit später keiner „Feuerwehr“ spielen muss

Das Supportende am 13. April 2026 ist ein klassischer Fall von „läuft doch“ vs. „ist verantwortbar“. Microsoft liefert keine Updates mehr für das Report Viewer Webpart und empfiehlt den Wechsel auf URL-Embedding als Alternative.
Wer heute inventarisiert, priorisiert und testet, hat im Frühjahr 2026 einen ruhigen Puls und einen unterbrechungsfreien Reporting-Service. Wer wartet, bekommt später ein Upgrade: nicht auf eine neue Version, sondern auf eine neue Art von Stress.

Und ganz nebenbei: Wenn ohnehin Modernisierung auf dem Plan steht, ist jetzt ein guter Zeitpunkt, Reporting strategisch zu sortieren – bis hin zu Power BI in SharePoint Online, wo das Einbetten als offizieller Weg dokumentiert ist.

Neu im Intranet: Copilot liest mit – und vor 🎧

Ab sofort bekommt unser Intranet eine praktische „Ohren-Option“: Microsoft 365 Copilot erzeugt KI-basierte Audio-Zusammenfassungen für Inhalte in SharePoint (Seiten und News-Beiträge) und in Viva Connections (News-Reader). Damit gibt es über Artikeln und News-Posts einen kurzen Audio-Überblick, der die Kernaussagen vorliest – wie ein Mini-Podcast, nur ohne Intro-Jingle und ohne „Lasst ein Abo da“.
Rollout: Ende Januar bis Ende Februar 2026.

Was bringt mir das im Alltag?

Kurzfassung: Weniger Scrollen, schneller Bescheid wissen.

• Pendeln: Kopfhörer rein, Audio-Überblick an, und schon bist du inhaltlich im Bild, bevor der Zug wieder entscheidet, ob er heute „Betriebsablauf“ kann.

• Multitasking: Während du E-Mails sortierst, unterwegs bist oder zwischen Terminen hängst, kannst du News „nebenbei“ aufnehmen. Microsoft nennt das ausdrücklich als „Listen your way“-Prinzip: weiterarbeiten und trotzdem hören.

• Schneller Kontext: Audio-Overviews liefern eine kompakte Kernaussagen-Version – ideal, um zu entscheiden: „Lese ich das komplett oder reicht mir die Kurzfassung?“

Wo taucht das auf?

Viva Connections (Teams, Desktop oder mobil)

• Audio-Briefings für die Top-News im Viva-Connections-News-Reader: Copilot fasst die Top 10 personalisierten News-Elemente als Audio zusammen.

SharePoint (Intranet)

• Audio-Zusammenfassungen auf SharePoint-Seiten und News-Posts – wenn auf der jeweiligen Site der SharePoint Knowledge Agent aktiviert ist.

Wichtiger Punkt: Es ist nicht „irgendwo im Nirwana“, sondern direkt dort, wo man ohnehin liest: auf der Seite bzw. über dem News-Beitrag.

In welchen Sprachen klappt das?

Microsoft erweitert hier die Sprachunterstützung. Konkret gilt:

• In Viva Connections läuft das Audio-Briefing in der Profil- oder Gerätesprache.

• In SharePoint wird die Audio-Zusammenfassung in der Sprache der Site bzw. der Seite erzeugt.

Heißt praktisch: Wer sein Profil/Endgerät (bzw. die Intranet-Site) auf Deutsch nutzt, bekommt das Feature auch „deutsch denkend und deutsch sprechend“ – sofern die jeweilige Sprache unterstützt ist.

Muss man etwas einrichten?

Die angenehmste Nachricht für alle, die schon genug Schalter am Tag umlegen: Nein.
Das Feature ist standardmäßig aktiviert und erfordert keine Admin-Konfiguration.

Datenschutz & Berechtigungen: Hört Copilot Dinge, die er nicht hören soll?

Nein. Copilot arbeitet innerhalb der bestehenden Berechtigungen:

• Du bekommst Audio-Overviews nur für Inhalte, auf die du ohnehin Zugriff hast.

• Es wird nichts „aus dem Nichts“ erfunden, sondern aus dem vorhandenen Seiteninhalt eine Audio-Zusammenfassung erzeugt. (Die bestehenden SharePoint-/Viva-Einstellungen gelten weiter.)

Praktische Tipps: So nutzt du das im Intranet clever

1. Audio zuerst, Text danach: Höre den Überblick an, entscheide dann, ob du den ganzen Beitrag brauchst. Das spart Zeit – besonders bei langen News.

2. „News-Routine“ bauen: Zwei Minuten Audio am Morgen (oder im Bus) reichen oft, um den wichtigsten Kontext zu haben.

3. Mobil nutzen: Audio ist ideal, wenn du gerade keine Lust auf Mini-Schriftgröße und Daumenakrobatik hast.

4. Sprache prüfen: Wenn dir die Ausgabe „komisch“ vorkommt, prüfe deine Profil-/Gerätesprache (Viva Connections) bzw. die Seitensprache (SharePoint).

Tipp für Führungskräfte: Botschaften barriereärmer platzieren

Audio-Overviews machen wichtige Informationen leichter konsumierbar – gerade für Kollegen, die:

• Inhalte lieber hören als lesen,

• unterwegs sind,

• oder sich durch lange Textwüsten kämpfen müssen.

Das erhöht die Chance, dass Kernbotschaften wirklich ankommen – nicht nur „veröffentlicht“, sondern auch „verstanden“.

Kleiner Realitätscheck (damit niemand später sagt: „Stand aber nicht im Newsletter“)

Die Experience in SharePoint hängt daran, dass auf der Site der SharePoint Knowledge Agent verfügbar/aktiv ist. In Viva Connections betrifft es News im News-Reader für Copilot-lizenzierte Nutzer.

So wird aus Intranet-Lesestoff ein kleines Stück „Intranet-Hörfunk“ – nur ohne Wetterbericht. (Den übernimmt ja schon der Blick aus dem Fenster.)