RSS migriert nicht automatisch zu RCD: So planen Sie Assessment und Cutover in SharePoint

Stand der Produktdokumentation: 14. September 2026. Verbindliches Publish-Gate: RSS-/RCD-Status, Stichtage und Produktgrenzen innerhalb von sieben Tagen vor Veröffentlichung erneut gegen die verlinkten Microsoft-Primärquellen prüfen und das Prüfdatum aktualisieren. Begriffsklärung: RSS bezeichnet in diesem Artikel Restricted SharePoint Search, nicht RSS-Webfeeds.

Microsoft blockiert seit dem 31. Juli 2026 neue Aktivierungen von Restricted SharePoint Search. Daraus folgt jedoch weder, dass bestehende RSS-Konfigurationen an diesem Tag automatisch abgeschaltet wurden, noch dass Microsoft sie automatisch in Restricted Content Discovery überführt. RCD ist keine technische Eins-zu-eins-Migration, sondern ein anderes, sitebezogenes Steuerungsmodell für Auffindbarkeit.[2]

Microsoft führt RSS als auslaufende Funktion und empfiehlt, sie nach validierten Berechtigungen und Governance-Kontrollen zu deaktivieren. Ein Abschaltdatum für bestehende Konfigurationen ist in der aktuellen Dokumentation nicht genannt.[2]

Für IT-Verantwortliche ist deshalb nicht die Frage „Wo ist der Migrationsschalter?“, sondern: Welche Schutzwirkung sollte RSS im eigenen Tenant vorübergehend liefern, welche Sites benötigen weiterhin eine begrenzte organisationsweite Auffindbarkeit – und welche Berechtigungs- und Governance-Probleme müssen unabhängig davon bereinigt werden?

RSS und RCD lösen nicht dasselbe Problem auf dieselbe Weise

Restricted SharePoint Search arbeitet mit einer Allowlist. Ist RSS aktiviert, bestimmt eine kuratierte Liste, welche SharePoint-Sites in organisationsweiten Suchanfragen sowie vorübergehend in Copilot- und agentischen Erlebnissen berücksichtigt werden. Die Liste umfasst bis zu 100 Sites; Hub-Sites zählen dabei als Eintrag, während zugeordnete Sites einbezogen werden können, ohne einzeln gegen dieses Limit zu zählen. Zusätzlich können Inhalte erscheinen, die Nutzende häufig besucht, direkt erhalten oder bereits angesehen, bearbeitet beziehungsweise erstellt haben.[2]

Das ist wichtig: RSS war und ist keine verlässliche Zugriffssperre. Microsoft bezeichnet es ausdrücklich nicht als Security Boundary. Vorhandene SharePoint-Berechtigungen werden nicht verändert, und die dokumentierten Ausnahmen verhindern die vereinfachte Aussage, nur Allowlist-Inhalte könnten gefunden oder von Copilot berücksichtigt werden.[2]

Restricted Content Discovery setzt an einer anderen Stelle an. RCD wird auf ausgewählte SharePoint-Sites angewendet und begrenzt deren Inhalte in organisationsweiten Sucherlebnissen und Microsoft-Copilot-Antworten. Auf einer betroffenen Site entfernt RCD außerdem sichtbare KI-Einstiegspunkte, darunter die Copilot-Schaltfläche, AI-Actions-Menüs einschließlich Agent-Erstellung und „Create pages with AI“.[1]

RCD entzieht aber keine Rechte. Wer bereits Zugriff auf Inhalte hat, kann sie weiterhin direkt öffnen. RCD entfernt Inhalte auch nicht aus dem Microsoft-365-Suchindex. Sitekontextbezogene Suche sowie intelligente Erlebnisse wie Microsoft 365 Feed und Recommendations sind laut Microsoft nicht von RCD abgedeckt. Auch die Zusammenfassung eines bereits geöffneten Dokuments wird dadurch nicht blockiert.[1]

Die präzise Kurzform lautet daher:

RCD begrenzt Discovery. Berechtigungen begrenzen Access. Beides darf nicht verwechselt werden.

Wer die SharePoint-Grundlagen hinter dieser Trennung auffrischen möchte, findet sie im WITC-Beitrag SharePoint Online – Die Basis für modernes Dokumentenmanagement. Für die Copilot-Perspektive ergänzt Copilot in SharePoint scheitert selten am Modell – sondern an eurer Basis den Zusammenhang zwischen Datenqualität, Berechtigungen und belastbaren Antworten.

Was „Cutover“ hier tatsächlich bedeutet

Ein RSS-to-RCD-Cutover ist keine Übertragung einer Allowlist in ein gleichartiges Zielobjekt. Er ist eine fachliche Neuentscheidung pro Site. Das bisherige RSS-Modell reduziert den organisationsweiten Suchraum auf eine Allowlist mit dokumentierten Ausnahmen. RCD markiert dagegen einzelne Sites, deren organisationsweite Auffindbarkeit zeitweise reduziert werden soll.[1][2]

Aus einer RSS-Allowlist lässt sich deshalb nicht automatisch eine RCD-Liste ableiten. Eine Site auf der RSS-Allowlist kann sauber berechtigt und für breite Discovery geeignet sein. Eine nicht gelistete Site kann dagegen wegen Oversharing, ungeklärter Ownership oder unkontrolliertem externen Teilen eine gezielte Prüfung benötigen. Hub-Strukturen verschärfen die Inventur: Bei RSS müssen Hub und zugeordnete Sites vollständig verstanden werden, obwohl sie nicht zwingend als einzelne Allowlist-Einträge erscheinen.[2]

Der sinnvolle Übergang besteht aus vier getrennten Arbeitssträngen:

1. Inventarisieren: bestehenden RSS-Status, vollständige Allowlist, Hub-Zuordnungen, Site-Eigentümer, Elementanzahl und Sharing-Signale erfassen.
2. Bewerten: pro Site entscheiden, ob sie organisationsweit auffindbar sein soll, vorübergehend RCD benötigt oder zuerst eine Berechtigungsbereinigung verlangt.
3. Kontrolliert umstellen: RCD in einem freigegebenen Scope setzen, Propagation und definierte Suchflächen beobachten und einen Rückweg vorsehen.
4. Dauerhafte Governance umsetzen: Ownership, Berechtigungen, Sharing, Restricted Access Control, SharePoint Advanced Management und Microsoft Purview jeweils nach ihrem tatsächlichen Zweck einsetzen.[1][2]

Microsoft beschreibt RCD ausdrücklich als temporäre Governance-Kontrolle für die Zeit, in der Zugriffe, Ownership und weitere Kontrollen geprüft werden. Selektiver Einsatz ist entscheidend: Zu viele RCD-Sites reduzieren den verfügbaren Kontext für organisationsweite Suche und Copilot und können Vollständigkeit und Relevanz der Ergebnisse beeinträchtigen.[1]

Explizite Claim-Grenzen für Kommunikation und Change Management

Zulässige Aussagen

• „Seit dem 31. Juli 2026 blockiert Microsoft neue RSS-Aktivierungen.“ Das entspricht der aktuellen RSS-Dokumentation.[2]
• „RCD begrenzt die organisationsweite Auffindbarkeit ausgewählter SharePoint-Sites in Suche und Copilot.“ Das beschreibt den dokumentierten Scope.[1]
• „RCD ändert vorhandene Berechtigungen nicht und entfernt Inhalte nicht aus dem Suchindex.“ Direkter Zugriff für bereits berechtigte Personen bleibt möglich.[1]
• „RCD ist nur auf SharePoint-Sites anwendbar, nicht auf OneDrive-Sites.“[1]
• „Die Wirkung ist nicht sofort garantiert.“ Bei Sites mit mehr als 500.000 Elementen kann die vollständige Verarbeitung laut Microsoft länger als eine Woche dauern.[1]
• „RCD ist eine temporäre Discovery-Kontrolle innerhalb einer breiteren Copilot-Readiness- und Governance-Strategie.“[1]

Nicht zulässige oder zu starke Aussagen

• Nicht: „RSS wurde am 31. Juli 2026 abgeschaltet.“ Die Quelle belegt die Blockade neuer Aktivierungen, nicht die automatische Deaktivierung jeder bestehenden Konfiguration.[2]
• Nicht: „Microsoft migriert RSS automatisch zu RCD.“ Dafür ist in den Primärquellen kein Automatismus dokumentiert.[1][2]
• Nicht: „RCD ist der RSS-Nachfolger mit identischer Wirkung.“ Allowlist und sitebezogene Discovery-Einschränkung unterscheiden sich strukturell.
• Nicht: „RCD sperrt die Site oder verhindert jeden Copilot-Zugriff.“ Direkter Zugriff, Site-Kontext und bereits geöffnete Inhalte sind davon zu unterscheiden.[1]
• Nicht: „RCD ersetzt Berechtigungsbereinigung, Restricted Access Control, Sensitivity Labels, DLP oder Purview.“ Microsoft ordnet RCD als Teil eines breiteren Kontrollmodells ein.[1][2]
• Nicht: „RCD ist sofort wirksam.“ Die Propagation hängt unter anderem von Site-Größe und parallelen Änderungen ab.[1]
• Nicht: „RCD schützt Microsoft 365 flächendeckend.“ Die Funktion ist auf SharePoint-Sites begrenzt und hat dokumentierte Ausnahmen.[1]

Wiederverwendbares Artefakt: RSS-to-RCD Assessment & Cutover Sheet

Das folgende Sheet ist als Arbeitsvorlage pro Tenant und Site gedacht. Es dokumentiert Entscheidungen; es ersetzt weder Change-Freigaben noch technische Prüfungen.

Bereich	Pflichtfelder
Tenant- und RSS-Baseline	Tenant-Kennung; RSS aktiviert/deaktiviert; ursprüngliches Enablement-Datum; Exportzeitpunkt in UTC; verantwortliche Administration
RSS-Allowlist	vollständige Site-URL; Eintragstyp; Hub-Site; zugeordnete Sites; Grund für Aufnahme; letzte fachliche Prüfung
Site-Inventar	Site-URL; Site-Typ; Elementanzahl; primärer und stellvertretender Owner; Fachbereich; Lebenszyklusstatus
Risikosignale	Sensitivität; breite Gruppen; organisationsweite Links; externe Freigaben; anonyme Links; verwaiste Ownership; bekannte Ausnahmen
Zielentscheidung	organisationsweit auffindbar; temporär RCD; zuerst Berechtigungen bereinigen; RAC prüfen; Purview-Maßnahme prüfen; stilllegen/archivieren
RCD-Change	gewünschter RCD-Status; fachliche Begründung; Change Owner; Freigabe; geplantes Zeitfenster; erwarteter Propagationskorridor
Testidentitäten	Identität A mit berechtigtem Zugriff; Identität B ohne Quellzugriff; Rollen und Gruppenmitgliedschaften; Testdatenfreigabe
Testflächen	organisationsweite SharePoint-Suche; Office.com/Bing-Suche; Microsoft Copilot; Site-Kontext-Suche; Direktlink; geöffnetes Dokument; Feed/Recommendations
Evidenzschema	Baseline-Ergebnis; erwartetes Ergebnis; beobachtetes Ergebnis; UTC-Zeitstempel; Screenshot- oder Log-Verweis; Abweichung; Prüfer
Audit und Rollback	Audit-Event-ID; Änderungsbegründung; Rollback Owner; Rollback-Zeitpunkt; RCD-Status nach Rücknahme
Abschluss	Berechtigungen bereinigt; Ownership bestätigt; weitere RAC-/Purview-Maßnahme; RCD entfernen/beibehalten; nächste Reviewfrist

Entscheidungsgate vor Aktivierung: Tenant und Lizenzvoraussetzungen, SharePoint-Advanced-Management-Voraussetzungen, RBAC, Site-Scope, Owner, fachliche Freigabe, Testidentitäten, erwartete Wirkung und Rollback müssen dokumentiert sein. Standardmäßig verwalten SharePoint-Administratoren RCD. Eine Delegation an Site-Administratoren muss tenantweit aktiviert werden; delegierte Änderungen verlangen eine Begründung.[1]

TESTPLAN – geplante Prüfung, keine ausgeführte Evidenz

Status dieses Abschnitts: Das folgende Verfahren ist ein reproduzierbarer Testplan. Es dokumentiert keine Ergebnisse aus einem WITC- oder Kundentenant und darf nicht als Nachweis einer erfolgreichen Umstellung zitiert werden.

1. RSS-Baseline sichern. RSS-Status, Allowlist sowie Hub- und Site-Zuordnungen exportieren. Zeitpunkt, ausführende Rolle und verwendete Verwaltungsoberfläche beziehungsweise Befehle festhalten.
2. Testscope festlegen. Zwei freigegebene SharePoint-Testsites auswählen: eine Site mit bewusst hergestelltem, nicht sensiblem Oversharing-Signal und eine Kontroll-Site. Keine realen vertraulichen Daten verwenden.
3. Identitäten prüfen. Für Identität A einen legitimen Site-Zugriff, für Identität B keinen Zugriff dokumentieren. Gruppenmitgliedschaften und Direktfreigaben vor dem Test festhalten.
4. Vorher-Messung durchführen. Für beide Identitäten jede im Sheet genannte Testfläche prüfen. Suchbegriff, Ergebnis-URL, Zeitstempel und Screenshot oder Logreferenz dokumentieren.
5. RCD im Testscope aktivieren. Im SharePoint Admin Center oder per dokumentiertem PowerShell-Befehl arbeiten: Set-SPOSite -Identity <Site-URL> -RestrictContentOrgWideSearch $true.[1]
6. Konfigurationsstatus prüfen. Den gesetzten Site-Status mit Get-SPOSite -Identity <Site-URL> | Select RestrictContentOrgWideSearch erfassen. Ein gesetzter Wert belegt die Konfiguration, noch nicht die vollständige Propagation.[1]
7. Propagation beobachten. Die definierten Testflächen in vorab festgelegten Intervallen erneut prüfen. Nicht aus einem einzelnen Suchresultat auf eine abgeschlossene tenantweite Verarbeitung schließen. Für große Sites einen längeren Beobachtungszeitraum einplanen.[1]
8. Erwartungen differenziert bewerten. Organisationsweite Discovery sollte sich gemäß RCD-Zweck verändern. Direkter Zugriff von Identität A, Site-Kontext-Suche, Feed/Recommendations und der Umgang mit geöffneten Dokumenten sind als getrennte Fälle zu protokollieren.[1]
9. RCD zurücknehmen. Im freigegebenen Testscope Set-SPOSite -Identity <Site-URL> -RestrictContentOrgWideSearch $false ausführen und die Rückkehr der Discovery mit demselben Messschema beobachten.[1]
10. Audit prüfen. Auditereignisse für Aktivierung, Deaktivierung und – bei delegierter Verwaltung – Begründung referenzieren. Microsoft dokumentiert diese Ereignisse für das Purview Audit Log.[1]
11. Abschlussentscheidung treffen. Pro Site festhalten, ob Berechtigungen bereinigt wurden, RAC oder Purview erforderlich ist, RCD entfernt werden kann oder eine befristete Verlängerung mit neuer Reviewfrist nötig ist.

Ein bestandener Test bedeutet nicht „Site ist sicher“. Er bedeutet nur, dass die erwartete Discovery-Wirkung im geprüften Scope und Zeitraum nachvollziehbar war. Die Zugriffssicherheit muss separat über Berechtigungen und passende Governance-Kontrollen bewertet werden.

Vom Übergangsprojekt zum belastbaren Betriebsmodell

Nach dem Cutover braucht RCD einen Owner, eine Begründung und ein Ablaufdatum. Ohne Wiedervorlage wird aus einer temporären Kontrolle schnell ein intransparentes Dauerprovisorium. Sinnvolle Betriebskennzahlen sind daher nicht nur die Anzahl eingeschränkter Sites, sondern auch Sites ohne bestätigte Owner, überfällige Reviews, offene Bereinigungsmaßnahmen, fehlende Rollback-Nachweise und Abweichungen zwischen RCD-Status und fachlicher Zielentscheidung.

Wenn intern Kapazität oder ein neutrales Review fehlen, kann WITC bei Inventur, Assessment-Design, Governance-Abgrenzung und einem kontrollierten Testlauf unterstützen. Der Einstieg erfolgt über die Kontaktseite – ohne Vorfestlegung auf RCD als Lösung für jede Site.

Weiterführende WITC-Artikel

• SharePoint Online – Die Basis für modernes Dokumentenmanagement – Informationsarchitektur, Dokumente und SharePoint-Grundlagen.
• Copilot in SharePoint scheitert selten am Modell – sondern an eurer Basis – Berechtigungen, Datenqualität und Copilot-Readiness im Zusammenhang.

Sources

[1] https://learn.microsoft.com/en-us/sharepoint/restricted-content-discovery — Microsoft Learn: Restrict discovery of SharePoint sites and content (Seitenstand 11.09.2026; abgerufen am 14.09.2026) [2] https://learn.microsoft.com/en-us/sharepoint/restricted-sharepoint-search — Microsoft Learn: Restricted SharePoint Search (abgerufen am 14.09.2026)