SharePoint Server 2016/2019/SE: Februar-2026-Updates gelistet

SharePoint-Patchday im Februar: Was genau ist gelistet – und wie bleibt die Farm nach dem Update geschniegelt?

Februar ist in vielen SharePoint-Farmen der Monat, in dem man sich kurz fragt, ob man lieber Briefmarken sammeln sollte. Dann siegt doch wieder die Vernunft: patchen, sauber dokumentieren, kontrolliert prüfen. Damit das kein Abenteuer wird, hier ein Consulting-Briefing mit den im Februar gelisteten SharePoint-Updates, Patchreihenfolge in der Farm, Backup/Restore-Logik, Post-Update-Checks, Rollback-Denken und einer Checkliste für die Change-Dokumentation.

1) Welche SharePoint-Updates im Februar gelistet sind (und warum das wichtig ist)

Für den Patchday rund um 10. Februar 2026 sind im Microsoft-Ökosystem SharePoint-Server-Updates gelistet – je nach Version getrennt nach „Core“ (Server) und ggf. Language Packs. Konkret tauchen im Update-Kontext unter anderem diese Einträge auf:

• SharePoint Server Subscription Edition: Security Update KB5002833 (Februar 10, 2026).
  Interessant: Laut Microsoft bringt dieses Update auch ein Feature-Update („Version 25H2 feature update“) mit. Das ist ein Hinweis, dass „Security Update“ in der Praxis auch funktionale Änderungen enthalten kann – und damit Testen noch wichtiger wird.

• SharePoint Server 2019: Security Update KB5002834 (Februar 10, 2026) plus separat Language Pack KB5002836.

• SharePoint Server 2016: Security Update KB5002841 plus Language Pack KB5002840.

Wenn du eine zentrale „Liste der Listen“ suchst: Microsoft führt SharePoint-Updates auch in einer Sammelseite („SharePoint updates“) zusammen, über die man sich in die jeweiligen KBs klickt.

Wichtig für die Praxis: Diese Februar-Updates adressieren u. a. Spoofing-Schwachstellen (laut KBs z. B. rund um Word/Outlook-Spoofing). Das heißt: Patchen ist nicht „nice to have“, sondern schlicht Risikoreduktion.

2) Patchreihenfolge in der Farm: Erst Hirn, dann Hände

SharePoint-Farmen mögen zwei Dinge: Reihenfolge und Geduld.

Grundprinzip: Du patchst die Server-Binaries, dann machst du die Farm-Konfiguration/Content-Datenbanken „fertig“ (PSConfig), und erst danach ist die Welt wieder rund.

Eine bewährte Reihenfolge (typischer On-Prem-Farm-Alltag):

1. Vorbereitung

   • Wartungsfenster, Monitoring, Stakeholder-Info, Change-Record.

   • Prüfen: genügend Platz auf Systemlaufwerken, Installer-Cache, Logs.

2. Patchen nach Rollen – kontrolliert

   • App-Server / Search / Distributed Cache / Spezialrollen zuerst (damit du nicht direkt am Frontend „abreißt“, falls etwas knirscht).

   • Web Front Ends (WFEs) danach – idealerweise nacheinander, damit wenigstens ein Knoten sauber bedient.

   • Central Administration nicht zwingend „zuerst“, aber bewusst: Viele machen CA zuletzt oder parallel zu einem App-Server. Wichtig ist nur: am Ende ist alles auf gleichem Patchlevel.

3. PSConfig/Upgrade-Schritt

   • Nach dem Patchen der Binaries: PSConfig (bzw. Products Configuration Wizard, wenn man es unbedingt klicken will) – am besten skriptbasiert und nachvollziehbar.

   • In Multi-Server-Farmen: erst auf einem Server durchziehen, dann die übrigen, je nach Konzept.

Merksatz: Nicht wild patchen wie ein Maulwurf im Garten. SharePoint ist eher Aquarium: langsam, geplant, mit Filterkontrolle.

3) Backup/Restore: Das Sicherheitsnetz, das man hoffentlich nie braucht

Vor Updates gilt: Backup ist keine Religion, sondern Mathematik. Entweder du kannst zurück, oder du kannst nicht.

Pragmatisches Minimum vor einem Farm-Update:

• SQL Backups aller relevanten Datenbanken:

  • Content-DBs

  • Service Application DBs (Search, Managed Metadata, User Profile etc.)

  • Config-DB und AdminContent-DB (ja, auch die)

• SharePoint-Farm-Komponenten:

  • Sicherung der Konfigurationsdateien, Zertifikate (falls relevant), IIS-Konfiguration (mindestens Export der Web.configs/Customizations)

• Suchindex? Je nach Setup: Oft ist es realistischer, Search nach Restore neu aufzubauen, statt einen Index „magisch“ wiederzubeleben. Plan das vorher ein (RTO/RPO).

Und jetzt der Punkt, den viele erst nach dem Knall lernen: Restore-Tests. Nicht jeden Monat ein komplettes Theaterstück, aber mindestens stichprobenartig: „Kann ich eine DB zurückholen und eine Webanwendung wieder starten?“ Sonst ist Backup eher Deko.

4) Post-Update-Checks: Search, Timer Jobs, ULS – die drei Musketiere

Nach dem Patch ist vor den Checks. Wenn du nur eine Sache konsequent machst: prüfen, bevor die Benutzer prüfen.

A) Search

• Search Service Application Status prüfen.

• Crawl-Komponenten und Query-Komponenten: laufen die Instanzen, sind sie „Healthy“?

• Testsuche über zentrale Sites (nicht nur Admin-Center).

• Ereignisanzeige + ULS auf Search-Warnungen scannen.

B) Timer Jobs

• „Timer Service“ läuft auf allen Servern?

• Kritische Jobs: Health Analyzer, Workflow Timer, Search-related Jobs.

• Nach PSConfig: schauen, ob Jobs „stauen“ (Queue wächst, Jobs hängen).

C) ULS / Event Logs

• Direkt nach Patch/PSConfig: ULS nach „Unexpected“, „Critical“, „Upgrade“ filtern.

• Event Viewer: Application/System auf .NET/IIS/SharePoint Errors.

• Health Analyzer Reports checken (gerne mit einem frischen Kaffee – die Wahrheit ist manchmal herb).

Bonus-Check (weil Klassiker): Central Admin öffnen, Webanwendungen erreichbar, ein typisches Team-Site-Szenario testen (Dokumentbibliothek öffnen, Upload/Download, Versionshistorie, ggf. Office-Integration).

5) Rollback-Denken: Kein Rückzug ist auch ein Plan – nur ein schlechter

Rollback ist bei SharePoint nie „ein Klick und zurück“. Darum lohnt es sich, vorher in zwei Stufen zu denken:

1. „Soft Rollback“ (Service-Wiederherstellung ohne komplette Rückkehr)

   • Problem ist nur ein Dienst? Dann: Dienstinstanzen neu starten, Cache leeren (vorsichtig), App Pools recyceln, betroffene Service Application neu provisionieren.

   • Oft reicht das, wenn es „nur“ ein hängender Timer Job oder eine zickige Search-Komponente ist.

2. „Hard Rollback“ (Restore)

   • SQL Restore auf Pre-Patch-Backups.

   • Farm-Binaries zurückdrehen ist selten hübsch. In der Praxis ist der sauberste Weg häufig: Farm-Stand wiederherstellen, dann Ursachenanalyse, dann neuer Patchlauf mit Fix.

Die wichtigste Rollback-Regel: Rollback ohne vorher klar definierte Stop-Kriterien ist wie Fallschirmspringen mit „wird schon“. Definiere vorher: Welche Symptome sind „go/no-go“?

6) Checkliste: Change-Dokumentation (damit du später nicht Detektiv spielen musst)

Hier die knackige Dokumentations-Checkliste, die in der Realität Gold wert ist:

• Change-Titel (z. B. „SharePoint SE – Februar 2026 Security Update KB5002833“).

• Betroffene Umgebungen (Prod, Test, DR; Farmname, Serverliste, Rollen)

• Ist-Stand: aktueller Build/ Patchlevel vor dem Update

• Soll-Stand: KB-Nummern + Ziel-Build (soweit angegeben)

• Risikoanalyse (Ausfall, Search-Neuaufbau, mögliche Customizations-Probleme)

• Backups: was, wann, wo, Restore-Pfad beschrieben

• Runbook: Schrittfolge inkl. Patchreihenfolge + PSConfig-Methode

• Validierungsplan: Post-Checks (Search/Timer/ULS), Smoke-Tests, Abnahmekriterien

• Rollback-Kriterien + Restore-Schritte

• Kommunikation: Ankündigung, Wartungsfenster, Abschlussmeldung

• Ergebnis: Start/Ende, Auffälligkeiten, Logs/Findings, Lessons Learned

Unterm Strich: Februar-Updates sind schnell installiert, aber die eigentliche Profi-Disziplin ist das Drumherum: Reihenfolge, Backups, Checks, und eine Doku, die auch am Montagmorgen nach drei Eskalationen noch Sinn ergibt. SharePoint verzeiht viel – aber er vergisst nichts.