Archiv der Kategorie: SharePoint 2019/SE

Forms Services auf SharePoint SE deaktiviert durch September CU

SharePoint, SharePoint 2019/SE

Bei einer aktuellen Migration von SharePoint Server 2019 auf SharePoint Server Subscription Edition bin ich auf ein Verhalten gestoßen, das für Betreiber bestehender InfoPath-Lösungen durchaus relevant sein dürfte.

Das Szenario war zunächst einfach und eindeutig:

✅ Testmigration durchgeführt

✅ Content-Datenbanken von SharePoint 2019 angebunden

✅ InfoPath Forms Services funktionierten

✅ Browserbasierte Formulare ließen sich wie erwartet öffnen

Anschließend wurde das September CU 2026 für SharePoint Server Subscription Edition installiert.

Danach änderte sich das Verhalten:

❌ Aufruf bestehender InfoPath-Formulare endet mit HTTP 410 „Gone“

❌ Im ULS findet sich zunächst kein wirklich hilfreicher Fehler

❌ Die Eigenschaft AllowUserFormBrowserRendering steht plötzlich auf $false nach der Ausführung von psconfig

❌ Set-SPInfoPathFormsService -AllowUserFormBrowserRendering $true lässt sich nicht mehr ausführen und verweist auf den deprecated Status von InfoPath

Eine erneute Migration mit dem gepatchten Farm-Stand zeigt dasselbe Verhalten. Microsoft hat also mit dem September CU die Forms Services komplett still gelegt.

Das Bemerkenswerte daran:

Microsoft hatte angekündigt, dass der Support für InfoPath Forms Services in SharePoint Server Subscription Edition am 14. Juli 2026 endet. In den Release Notes des September Cus ist aber kein Hinweis zu finden, dass mit diesem Update auch eine technische Abschaltung des serverseitigen InfoPath-Renderings erfolgt. Bei den SharePoint 2010 Workflows sieht das anders aus, aber diese lassen sich wieder aktivieren.

Das ist ein erheblicher Unterschied:

„Nicht mehr unterstützt“ und „funktioniert nach Installation eines CUs nicht mehr“ sind für den Betrieb einer bestehenden SharePoint-Farm zwei sehr unterschiedliche Aussagen.

Für Umgebungen, in denen noch InfoPath-Formulare produktiv eingesetzt werden, würde ich daher dringend empfehlen, das September CU 2026 zunächst in einer Testfarm gegen die eigenen Formulare zu prüfen.


Disclaimer: Ja, ich weiß, dass die Forms Services auf der SharePoint Conference 2014 abgekündigt wurden. Dennoch gibt es noch den einen oder anderen Kunden, der es bisher nicht geschafft hat, sich davon zu lösen. “Solange es läuft …” ;).

Update: Microsoft hat glücklicherweise reagiert und einen weiteren Patch herausgebracht mit einer Anleitung, wie die Forms Services wieder zum Laufen gebracht werden können. Stefan Goßner hat das auf seinem Blog veröffentlicht: https://blog.stefan-gossner.com/2026/09/21/trending-issue-infopath-forms-issues-with-sp2010-workflows-after-september-2026-cu

Wichtig: Nach der Patch-Installation ERST das PowerShell-Script ausführen und danach psconfig. Das Update enthält und ersetzt damit das September CU, ist aber nicht auf der Updates-Seite sichtbar. Der Link zum Patch ist im Blog von Stefan enthalten.

Und noch wichtiger: Microsoft wird ankündigen, wann die Forms Services und wie SP2010 Workflows endgültig aus dem Produkt entfernt werden, also: Patch Notes genau lesen!

Damit geht eine Ära zu Ende, die zu meinen Anfangszeiten begonnen hat: SharePoint Designer, InfoPath Designer und die Prozess-Automatisierung mit SharePoint im klassischen Sinne 😢 .

Wer jetzt noch SP2010-Workflows und InfoPath im produktiven Einsatz hat, für den ist es jetzt wieder 5 vor 12. Microsoft hat die Uhr nochmal ein paar Minuten zurück gedreht ;).

Problem beim Crawling von SharePoint 2019/SE mit ADFS-Authentifizierung

ADFS, Authentifizierung, SharePoint, SharePoint 2019/SE, , , , ,

Heute war mal wieder so ein Tag, der einen die Haare raufen lässt: Geplant ist eine Migration von SharePoint 2013 nach SharePoint SE. Allerdings nicht Standard, sondern eine etwas ungewöhnlichere Konfiguration: Mit ADFS zur Authentifizierung gegen einige Active Directories im Hintergrund.

Hierzu ist u.A. eine spezielle Logon-Page implementiert worden, die je nach Client-IP auf ADFS- oder auf Windows-Authentication weiterleitet (vairam-svs/spautosignin). Damit sollen die Suchserver die Windows Authentication erhalten, was bei der alten Umgebung einwandfrei funktioniert hat. Nur diesmal eben nicht.

Das Phänomen: Der Crawler bricht der Crawl-Vorgang direkt mit einer Warnung ab:

The start address https://xxx.xxx.xx cannot be crawled. Context: Application ‘Search_Service_Application’, Catalog ‘Portal_Content’ Details: Item not crawled due to one of the following reasons: Preventive crawl rule; Specified content source hops/depth exceeded; URL has query string parameter; Required protocol handler not found; Preventive robots directive. (0x80040d07)

Die erste Idee …

Natürlich hatte ich erst mal die Authentifizierung im Sinn (“query string parameters”), bei der MySite hat alles funktioniert. Also den kompletten Code der Extension auseinander genommen, verändert, getestet usw. Dabei habe ich dann tatsächlich noch einen Fehler gefunden, der aber nicht relevant war: Der Redirect auf Windows Authentication funktionierte nicht, weil der DisplayName des ClaimsAuthenticationProviders unter bestimmten Umständen nicht “Windows Authentication”, sondern “Windows-Authentifizierung” enthält (*ächz*). Hat dann aber auch nichts am Fehler geändert.

… war ein Reinfall. Nächste, bitte!

Nächster Schritt: Alles Suchrelevante auf Verbose stellen und 300MB ULS-Log durchforsten. Auch nichts verwertbares. Aber irgendwas war komisch, im IIS-Log des WFE steht nur ein Request drin, nämlich auf die “robots.txt”. Und nun steht da drin “Disallow: /”!

Die Erklärung

SharePoint seit mindestens 2019 hat einen Mechanismus, der vor externen Crawlern schützen soll. Der wird automatisch aktiviert, wenn eine Web Application Anonymous Access aktiv hat. OK, meine WebApp hat das nicht, aber Windows Authentication und Claims Based Authentication gleichzeitig. Und CBA fällt auch in diese Kategorie (warum auch immer), daher generiert SharePoint dann automatisch dieses robots.txt, die vom Crawler selbst auch berücksichtigt wird.

Die Lösung

Die Deaktivierung der Funktion ist ganz einfach: XmlSitemap-Feature auf der obersten Site aktivieren:

Enable-SPFeature XmlSitemap -Url https://xxx.xxx.xx/

Das sorgt automatisch für eine Deaktivierung der Funktion und schon kann der Crawler wieder richtig crawlen.

Fazit: Es läuft wie immer, je schwerer nachvollziehbarer ein Problem und je mehr Aufwand man betreibt, um dem Problem auf den Pelz zu rücken, desto einfacher ist die Lösung am Ende …