Fix-SeptemberCU-Permission-Problem.ps1
Alternatively you can also remove the NT Authority\system account from WSS_WPG and IIS_IUSRS local security groups of the SharePoint machines.
For more details check this article: Trending Issue: SharePoint fixes fail to install after installation of September 2025 CU
The product group released the September 2026 Cumulative Update for SharePoint Server Subscription Edition.
Monthly SharePoint Server Subscription edition updates are released as a single unified “uber” package containing both the language independent and language dependent fixes. Language independent and language dependent fixes will no longer be released separately. This is similar to the full server packages released for SharePoint 2013.
The KB article for September 2026 CU will be available at the following location in a couple of hours:
- KB 5002908 – September 2026 Update for SharePoint Server Subscription Edition
This is also a security update!
The download for September 2026 CU is available through the following link:
It is irrelevant which language you pick on the drop down in download center. It will always download the same package.
After installing the fix you need to run the SharePoint Products Configuration Wizard on each machine in the farm. If you prefer to run the command line version psconfig.exe ensure to have a look here for the correct options.
Please ensure to have a look at the SharePoint Patching Best Practices before applying new fixes.
SharePoint Server Subscription Edition September 2026 CU Build Number: 16.0.20326.20136
Important: To minimize the installation time for SharePoint Server Subscription Edition Fixes, please follow the guidance in the following article: Solving the extended install time for SPSE CUs
Related Links:
- Learn: Updated Product Servicing Policy for SharePoint Server Subscription Edition
- Learn: FAQs for SharePoint Server Subscription Edition product servicing policy
- Blog: SharePoint Patching Best Practices
- Blog: SharePoint Patching demystified
- Blog: Why I prefer PSCONFIGUI.EXE over PSCONFIG.EXE
- Learn: SharePoint Updates
- Blog: SharePoint Server 2016 Zero-Downtime Patching Demystified (applies also to SharePoint Server 2019)
- Blog: SharePoint does not have a build version. Full Stop.
- Blog: Solving the extended install time for SPSE CUs
Permalink
We are getting an error on multiple farms when running psconfig for this update.
An exception of type Microsoft.SharePoint.Upgrade.SPMissingAttributeException was thrown. Additional exception information: The TargetSchemaVersion Attribute for class [Microsoft.Office.InfoPath.Server.Upgrade.RegisterInfoPathDeprecationHttpModule] requires To and From build information.
Permalink
Hi B,
please open a ticket with Microsoft support to ensure this is properly analyzed.
Cheers,
Stefan
Permalink
Thanks, We have already done so
Permalink
Hi B,
it seems you downloaded the fix before the KB articles was published.
5 hours ago the correct fix was uploaded with version 16.0.20326.20136
Please redownload and install the correct fix.
Cheers,
Stefan
Permalink
we are also facing same error, any luck with fix
Permalink
Hi Karteek,
ensure to redownload the fix and verify the version 16.0.20326,20136.
Older builds experience this problem.
Cheers,
Stefan
Permalink
Thanks Stefan, 16.0.20326,20136 is resolved the issues.
Permalink
Hi Stefan,
Has the Distributed Cache issue reported by multiple customers after the August 2026 SPSE CU (CacheHostIsNull, non-compliant cache hosts, failures during PSConfig, and “No host present in the cluster” errors) been fixed in the September 2026 CU? (It’s not listed in the fixes).
We experienced similar symptoms in our farm and would like to know whether Microsoft considers the issue resolved or whether the existing workaround is still recommended.
Permalink
The fix is targeted for the October PU release.
Permalink
Hi MK,
no – this fix is still in development.
In case that a new distributed cache server needs to be provisioned the workaround with the ServerDebugFlag needs to be applied:
$farm = Get-SPFarm
$farm.ServerDebugFlags.Add(59052)
$farm.update()
With this setting provisioning a new DCACHE server should work.
After the provisioning is completed, please revert the setting using
$farm = Get-SPFarm
$farm.ServerDebugFlags.Remove(59052)
$farm.update()
Cheers,
Stefan
Permalink
Thank you, Stefan, for sharing this workaround. Unfortunately, it did not solve the issue in our environment, so I have opened a Microsoft support case to investigate it further.
Permalink
Thank you – this helped me a lot while setting up a new SP SE farm!
Permalink
Hi Stefan,
Greetings of the Day!!
We wanted to bring an issue to your attention regarding the September 2026 SharePoint Server Subscription Edition updates.
As of today, we are not seeing the September SharePoint updates published in the Microsoft Update Catalog. Our environment normally receives these updates through WSUS, but this month they are not appearing as expected. In WSUS, we only see previous SharePoint Server Subscription Edition updates, and no new updates for September.
We have confirmed that the September SharePoint Server Subscription Edition updates are not currently available in the Microsoft Update Catalog, and this is preventing us from deploying the latest security patches in our environment.
Could you please check if there is any known delay or issue with the publication of the September SharePoint updates?
Thank you for your assistance.
Best Regards,
Yanala Chandra Mohan Reddy
Permalink
Hi Yanala,
please check again now. There was a problem with the catalog server which caused this. But it has already been resolved.
Cheers,
Stefan
Permalink
Thankyou Stefan !!
Permalink
Hi Stefan,
Have you had reports of friendly URLs (managed meta data) not appearing in the search index?
After the August 2026 CU our friendly URL pages all stopped appearing in our search results. We had a few .aspx pages that were set to not hide physical URL from search, and those ones are appearing in in the index. All of our PDF documents are appearing in the index too.
We re-imaged a server to the July 2026 CU, cleared the index, and ran a full crawl, and it found our friendly URLs. We then updated to August 2026 CU, cleared the index, and ran a full crawl, and our friendly URLs were now missing. We have also installed the September 2026 CU and it didn’t resolve our issue.
We are on SE and using a publishing site.
Thanks in advance,
David
Permalink
Hi David,
I would recommend to open a support case to get this analyzed.
Cheers,
Stefan
Permalink
Hi David, I fixed this same problem with Search crawler x Term Store after the Aug CU by running the following commands in powershell
$farm = Get-SPFarm
$farm.AddGenericAllowedListValue(“BCSAllowedTypeNames”, “Assembly=Microsoft.Office.Server.Search.Connector, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c|Namespace=Microsoft.Office.Server.Search.Connector.BDC.TopicPagesConnector|TypeName=TopicPagesConnector”)
$farm.AddGenericAllowedListValue(“BCSAllowedTypeNames”,”Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089|Namespace=System|TypeName=Object”)
$farm.AddGenericAllowedListValue(“BCSAllowedTypeNames”,”Assembly=System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089|Namespace=System.Data|TypeName=IDataReader”)
$farm.AddGenericAllowedListValue(“BCSAllowedTypeNames”,”Assembly=Microsoft.Office.Server.Search.Connector, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c|Namespace=Microsoft.Office.Server.Search.Connector.BDC.TopicPagesConnector|TypeName=TaxonomyProperty”)
$farm.AddGenericAllowedListValue(“BCSAllowedTypeNames”,”Assembly=System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089|Namespace=System.Data|TypeName=IDataRecord”)
$farm.AddGenericAllowedListValue(“BCSAllowedTypeNames”, “Assembly=Microsoft.Office.SecureStoreService, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c|Namespace=Microsoft.Office.SecureStoreService.Server|TypeName=SecureStoreProvider”)
$farm.AddGenericAllowedListValue(“BCSAllowedTypeNames”,”Assembly=Microsoft.Office.Server.Search.Connector, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c|Namespace=Microsoft.Office.Server.Search.Connector.BDC.TopicPagesConnector|TypeName=TaxonomyProperty[]”)
$farm.AddGenericAllowedListValue(“BCSAllowedTypeNames”,”Assembly=Microsoft.Office.Server.Search.Connector, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c|Namespace=Microsoft.Office.Server.Search.Connector.BDC.TopicPagesConnector|TypeName=TaxonomyRootWeb”)
$farm.AddGenericAllowedListValue(“BCSAllowedTypeNames”,”Assembly=Microsoft.Office.Server.Search.Connector, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c|Namespace=Microsoft.Office.Server.Search.Connector.BDC.TopicPagesConnector|TypeName=TaxonomyRootWeb[]”)
$farm.AddGenericAllowedListValue(“BCSAllowedTypeNames”,”Assembly=mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089|Namespace=System|TypeName=Byte[]”)
$farm.AddGenericAllowedListValue(“BCSAllowedTypeNames”,”Assembly=Microsoft.Office.Server.Search.Connector, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c|Namespace=Microsoft.Office.Server.Search.Connector.BDC.TopicPagesConnector|TypeName=TaxonomyWeb”)
$farm.AddGenericAllowedListValue(“BCSAllowedTypeNames”,”Assembly=Microsoft.Office.Server.Search.Connector, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c|Namespace=Microsoft.Office.Server.Search.Connector.BDC.TopicPagesConnector|TypeName=TaxonomyWeb[]”)
$farm.AddGenericAllowedListValue(“BCSAllowedTypeNames”,”Assembly=Microsoft.Office.Server.Search.Connector, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c|Namespace=Microsoft.Office.Server.Search.Connector.BDC.TopicPagesConnector|TypeName=TaxonomyTerm”)
$farm.AddGenericAllowedListValue(“BCSAllowedTypeNames”,”Assembly=Microsoft.Office.Server.Search.Connector, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c|Namespace=Microsoft.Office.Server.Search.Connector.BDC.TopicPagesConnector|TypeName=TaxonomyTerm[]”)
$farm.Update()
And then i restarted SharePoint Search Host Controller and SharePoint Search 16 services.
This was discussed in https://blog.stefan-gossner.com/2026/08/14/trending-issue-bcs-type-is-not-in-the-bcsallowedtypenames-generic-list-after-august-2026-cu/
Permalink
Thank you so much for this William. That worked perfectly.
Permalink
Hi Stefan,
Seems that our SharePoint 2010 workflows are broken after September CU even when “Enable-SPLegacyWorkflow”. we have also set the EnablePreParseSecurityCheckForWorkflow = $false on the farm.
For simplicity I cannot create a simple list and add a standard 2010 approval workflow. I get the following error:
The specified form template could not be found, or is not compatible with rendering in the browser. It might need to be republished as a browser-enabled form.
Click Try again to attempt to load the form again. If this error persists, contact the support team for the Web site.
Click Close to exit this message.
Permalink
I am getting the same issue with the September CU. The issue seems to be around the CstWrkflIP.aspx page and form.
Permalink
A workaround has now been released:
https://blog.stefan-gossner.com/2026/09/21/trending-issue-infopath-forms-issues-with-sp2010-workflows-after-september-2026-cu/
Permalink
We experience issues on some SharePoint 2010 workflows, but not on all. Some workflows can be started manually and continue to work. On some workflows the GUI to start the workflows shows “Unable to display this Web Part.”.
Some SharePoint 2010 workflows don’t start automatically anymore when a list item is created or modified. These workflows can be started manually. When we published the affected workflow again, we ran into the first issue, that the Web Part doesn’t show up anymore 🤷♂️🤦♂️
➡️ How likely is it that this will be resolved? ❓
ℹ️Details about “Unable to display this Web Part.”
1️⃣ ULS shows it’s because the DataFormWebPart is blocked for security reasons.: “Re-definition of tag cc2:DataFormParameter found, maintaining consistency of attributes across duplicate tags for security. To bypass validation, disable farm property ‘PreserveAttributeConsistency’. “
2️⃣When I disable PreserveAttributeConsistency on the SPFarm, I get another error: “WPProperty has been blocked for security reason. blocked AssemblyQualifiedName is Microsoft.SharePoint.WebPartPages.DataFormWebPart, Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c | blocked property name is ManualRefresh”
3️⃣When I extend web.config with AllowedWPProperties.AllowedWPProperty type=”Microsoft.SharePoint.WebPartPages.DataFormWebPart ….” then I get “Error while executing web part: System.Xml.Xsl.XslLoadException: The named template ‘dvt_1.header’ does not exist. An error occurred at (38,3).” …
4️⃣This seems to be unsolvable, except by disabling lots of the new XSLT protection mechanisms.
Permalink
After updating Event Receivers from Version 15 to 16 existing Workflows start again automatically.
See https://github.com/media-service-dev/sharepoint-powershell/blob/master/Update-EventReceiverVersionTo16.ps1
Thanks @Thomas 🚀👏
Permalink
Great Post. This powershell script really saved my day for custom made SP2010 Workflow activities and SP2010 Workflows. Everything started automatically again after running this script!
Permalink
Same here, I just made a post in the comments of the “Are you using SP2010 or SP2013 workflows in your SharePoint farms? ” article on this site.
Permalink
Hi Jan,
are you using InfoPath forms within this workflow?
Cheers,
Stefan
Permalink
Hi Stefan,
The one SharePoint Designer workflow we have running in production does. After CU it does not trigger when a new item is created on our list and we cannot edit and publish the workflow again. Here we get the same error when publishing as we do on a simple standard 2010 approval workflow mentioned before. This is happening on all farms we have patched with this CU.
Permalink
hi, all,
I understand that there are no workarounds or solutions yet for this issue with InfoPath and Workflows, correct? Thanks for you help.
Permalink
A workaround has now been released:
https://blog.stefan-gossner.com/2026/09/21/trending-issue-infopath-forms-issues-with-sp2010-workflows-after-september-2026-cu/
Permalink
The Ability to Publish New 2010 style workflows has been removed from the product the mentioned PowerShell commands will not change that behavior.
Permalink
Hi Jan,
Jacobs statement is correct.
SP2010 workflows are unsupported since July 2026 CU.
September CU disables SP2010 workflows and prevents creation of new workflows.
In case that existing workflows are still required the PowerShell commands can be used to reenable SP2010 workflows – but creation of new workflows is not possible as customers should focus on migrating the existing workflows to a new platform (2013, Flow, or alternatively 3rd party).
Cheers,
Stefan
Permalink
Hi Stefan,
With the October CU, will new SP2013 workflows also be blocked?
Thank you,
Chad
Permalink
Stefan – Is Updating/Republishing 2010 workflows still doable? i.e. is this lock only on creating new ones but existing ones are ok?
Permalink
Hi Lee,
afaik republishing is blocked.
Cheers,
Stefan
Permalink
Testing Workflows 2010 reveals the following: With
Enable-SPLegacyWorkflow, simple workflows start without issues for created and changed items. Only manual starting triggers an InfoPath error. In SharePoint Designer, workflows can only be edited and published if the manual start option is unchecked. I have been working with SharePoint for a long time, yet I never really realized that InfoPath is involved in manual starts.Permalink
Hello Stefan, long time follower of your blog! At the risk of sounding a bit dense: I do recognize that we’ve been warned for several months that SP2010 & SP2013 workflows were now unsupported and that with September CU would be disabled by default. However with all of those warnings we were also told about the commands that would allow us to re-enable SP2010 and SP2013 workflows if we were willing to accept the risks. At no point can I discern that we were warned by Microsoft that these re-enable commands would not also allow for creation of new workflows or re-publishing of existing workflows. I gather some might think that should be obvious from the word “unsupported”, but I respectfully disagree. Even the KB article for the September 2026 CU doesn’t explain this situation, it says:
“Notifies that the SharePoint 2010 Workflow feature will be disabled starting with the September 2026 Cumulative Update. To enable the feature for a site collection, use the Enable-SPLegacyWorkflow cmdlet. To disable the feature, use the Disable-SPLegacyWorkflow cmdlet. To view all site collections for which the feature is enabled, use the Get-SPLegacyWorkflowEnabledSites cmdlet.”
Would it be possible to request a Microsoft article or KB or something that fully spells out all effects of the September 2026 CU, most specifically that new SP2010 workflows can no longer be created at all, nor can existing SP2010 workflows be re-published?
Permalink
Hi David,
yes – I understand your frustration.
Unfortunately Microsoft does not plan to publish a separate article about this topic as this feature is no longer supported and allowing to enable the use of already registered workflows while migration to a new platform is on the way is a curtesy.
Btw: SP2013 workflows remain fully supported.
Cheers,
Stefan
Permalink
Hi Jan,
a workaround has now been released:
https://blog.stefan-gossner.com/2026/09/21/trending-issue-infopath-forms-issues-with-sp2010-workflows-after-september-2026-cu/
Cheers,
Stefan
Permalink
With this update, I’ve noticed that using custom tiles across web application boundaries no longer works. Instead, when accessing the MySite (for example), an entry appears in the event log stating that access to the database containing the centrally managed custom tiles was denied for the MySite web application’s application user.
If I grant permissions to the database hosting the central list, it works again. Was there a change here?
Permalink
I am using Workflows 2010 and have enabled legacy workflows (
Enable-SPLegacyWorkflow). However, I cannot start workflows manually; I receive the error: “The specified form template was not found.”When running
Get-SPInfoPathFormsService,AllowUserFormBrowserRenderingis set to$false.However, I cannot set it to
$true:Set-SPInfoPathFormsService : User form browser rendering is no longer supported because InfoPath is deprecated.On a farm without the September CU, manual startup works, and
AllowUserFormBrowserRenderingis$true. (For any Workflow 2010 created in SharePoint Designer that is configured for manual startup, a form file namedWorkflowName.xsnis automatically created.)Permalink
I am facing the same issue.
Get-SPInfoPathFormsService |
Select-Object `
AllowUserFormBrowserEnabling,
AllowUserFormBrowserRendering
AllowUserFormBrowserEnabling AllowUserFormBrowserRendering
True False
I am unable to set AllowUserFormBrowserRendering
PS D:\test> Set-SPInfoPathFormsService -AllowUserFormBrowserRendering true
Set-SPInfoPathFormsService : User form browser rendering is no longer supported because InfoPath is deprecated.
At line:1 char:1
+ Set-SPInfoPathFormsService -AllowUserFormBrowserRendering true
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (Microsoft.Offic…msServiceCmdlet:SetFormsServiceCmdlet) [Set-SPInfoPathFormsService], NotSupportedException
+ FullyQualifiedErrorId : Microsoft.Office.InfoPath.Server.Cmdlet.SetFormsServiceCmdlet
Permalink
Hi Meena,
this issue is currently under investigation by our product group.
Cheers,
Stefan
Permalink
A workaround has now been released:
https://blog.stefan-gossner.com/2026/09/21/trending-issue-infopath-forms-issues-with-sp2010-workflows-after-september-2026-cu/
Permalink
Hi Stefan,
Hope you are Doing Great 🙂
After installing the September 2026 SE security update (KB5002908, build 16.0.20326.20136) we see site / subsite provisioning fail on old site collections only. Brand-new site collections on the same farm provision normally.
Symptom
Creating a publishing web (OOB publishing template) fails with:
Failed to create the ‘Images’ library
OriginalException: Operation is not valid due to the current state of the object
ULS during AreaProvisioner.CreateImagesLibrary → SPEventReceiverDefinitionCollection.GetSqlToAddEventReceivers / type load:
Could not load file or assembly ‘Microsoft.Office.DocumentManagement, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’
DocumentManagement.dll on disk is 16.0 only. There is no 15.0 GAC copy, which is expected on SE.
Where 15.0 is coming from
Not farm features. It is baked into content that survived the 2013/2016 → SE upgrade:
• Site content types Document Set, Video, System Media Collection — in SchemaXml still name Version=15.0.0.0 (sometimes mixed with 16.0 DocId receivers in the same CT).
• Child Document Set CTs (custom children of 0x0120D520) on each library keep their own SchemaXml copy; updating the parent CT to 16.0 does not rewrite the children. SchemaXmlWithResourceTokens replace + Update($false) on the list CT often snaps back to 15.0 until the site-scoped child CT is updated first.
• Site- and list-scoped event receivers still registered with Assembly = … Version=15.0.0.0.
• A saved site template (WSP from a publishing web) embeds the same 15.0 strings in Elements.xml, ElementsContentType.xml, and every Files\\Schema.xml. Save-as-template also emits ListInstance rows for _catalogs/design and _catalogs/masterpage with FeatureId=”{00000000-0000-0000-0000-000000000000}”, which then fail config lookup during ListInstances.
New site collections never had those 15.0 strings, so Images / VideoSet provision with 16.0 and succeed.
What is not a documented match
KB5002908 does not mention publishing, Images, or Document Set receivers. We are treating it as content leftover + stricter assembly load after a security CU, not as “every SE farm is broken.”
Questions
1. Is there an intended post-CU behavior that refuses to bind event receivers whose assembly version is not on disk (15.0 on a 16.0-only farm), and should that be called out for upgraded publishing / Document Set sites?
2. Is rewriting SchemaXml 15.0 → 16.0 on Document Set / Video / child CTs the supported cleanup, or is there a feature repair / Enable-SPFeature path that rebuilds those from the 16.0 product CTs without hub republish?
3. Save site as template from a publishing web: is stripping catalog ListInstance rows and 15.0 assembly strings still the only
Thanks,
Chandra Mohan Reddy Yanala
Permalink
Hi Chandu,
please apply this:
$farm = Get-SPFarm
$farm.AddGenericAllowedListValue(“AllowedDLCAssemblies”, “Microsoft.Office.DocumentManagement, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”)
$farm.Update()
Cheers,
Stefan
Permalink
Hi Chandu,
I think I have the same problem as you but I’m creating a subsite as a team site (STS#0).
If you have a DEV or TEST environment with this issue can you try to create a basic out-of-the-box team site in your old site collection using something like the following powershell? It is failing for me and sounds like it would fail for you too.
New-SPWeb -Url “https://sitecollection/subweb1” -Name “My Team Subsite” -Template “STS#0”
Regards,
Rob
Permalink
Hi Chandu,
you can use the script below to fix this:
https://github.com/media-service-dev/sharepoint-powershell/blob/master/Update-EventReceiverVersionTo16.ps1
Ensure to update the assembly references in the script.
In your case
$oldAssembly = “Microsoft.Office.DocumentManagement, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”
$newAssembly = “Microsoft.Office.DocumentManagement, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”
Cheers,
Stefan
Permalink
Hello Stefan,
I had the same problem with enabling the AllowUserFormBrowserRendering after installing the September CU.
I found that Microsoft added a new check in Microsoft.Office.InfoPath.Server.dll:
if (value)
{
throw new InvalidOperationException(
“User form browser rendering is no longer supported because InfoPath is deprecated”);
}
This code prevents the option from being enabled.
I found a workaround to enable the option again:
1. Backup the InfoPath DLL before installing the CU.
2. Install the CU.
3. Temporarily replace the DLL with the old version.
4. Enable AllowUserFormBrowserRendering with: Set-SPInfoPathFormsService -AllowUserFormBrowserRendering $true
5. Restore the DLL from the CU.
6. Restart the servers.
After this, the CU is still fully installed and the CU version of the DLL is back in place. However, the option remains enabled:
AllowUserFormBrowserRendering : True
Permalink
Hi Zied!
Did you have to restart service or server when replaced the dll?
Regards,
/M
Permalink
Thank you for the workaround Zied, but it does not resolve the issue. Indeed, the AllowUserFormBrowserRendering property is set to false after installing the CU, but after testing, even when setting this property to TRUE, InfoPath forms no longer work, which affects all 2010 workflows.
As indicated by the error mentioned by B in the first comment, there is also a new HTTP module, “InfoPathDeprecation,” which is registered in the web.config by the September Cumulative Update. At first glance, it appears that the InfoPath service has been completely deprecated and blocked at many stages of code.
This is very problematic because, for example, a Site Workflow includes a form by default to start the workflow. I imagine that all out-of-the-box workflows 2010, such as Approval or Data Collection, no longer work either.
The end of support for InfoPath was announced a long time ago, but the fact that InfoPath is being completely removed from the Subscription Edition after this CU was never communicated or until know i could not find the page where it was mentioned.
This is a difficult situation because our customers who use our on-premises SharePoint service are in the middle of migrating to Workflow 2013. I hope there’s still a way to restore InfoPath. Perhaps Stefan can help us with this? Thanks in advance.
Permalink
The key page seems to be this one: https://learn.microsoft.com/en-us/sharepoint/what-s-new/what-s-deprecated-or-removed-from-sharepoint-server-subscription-edition
Which lists both InfoPath Forms and 2010 Workflows as deprecated and end-of-support as of July.
However, it also says:
“Unless there are exceptional circumstances, Microsoft will provide advance notice before a deprecated feature is removed by a future update.”
Would be nice to know if there were exceptional circumstances for InfoPath. Even if it had been mentioned I, for one, didn’t know the default 2010 workflows had a reliance on InfoPath.
Permalink
Hi,
I know that Infopath and 2010 workflows are deprecated but we still use some Infopath forms (without a workflow). Since I haven’t installed the September CU on our test system yet, can someone tell me if “normal” Infopath forms on a custom list are also affected (not loading) or does this only happen within a SharePoint Designer workflow?
Thanks in advance,
Alex
Permalink
Hi Alex,
this affects also InfoPath forms outside of Workflows.
Cheers,
Stefan
Permalink
Hi Stefan,
thanks for the update. Is this a bug an will the InfoPath forms work with a later CU Update again or are we done with them?
Thanks in advance,
Alex
Permalink
Hi @Didier
It’s true that Approval workflows rely on infopath forms. I imagine they are a still widely use since they provide a convinient, ready-made solution for running approval processes. There is nothing similiar ready made in WF2013 as far as i know.
It increasingly feels like MS is punishing “On Prem” users with pathreleases that create Issues.
Since April, i’ve encountered problems in my farms.
Permalink
I used this article to help me re-write the 2010 Approval workflows. It wasn’t as bad as I thought. https://www.spguides.com/sharepoint-designer-workflow-examples/
If the person initiating the approval is the person that does the approval, I skip the approval process. So, the workflow looks like:
If workflow contentxt:Initiator equals {approvers name}
set variable: strOutcome to Approved
then Set WorkflowStatus to strOutcome
ELSE
Add 4 days to Today (Output to variable:strDueDate)
then email workflow context:Initiator
then ‘Assign a task’ to {approver} (Task outcome to Variable:Outcome |Task ID to Variable: TaskID)
if variable:Outcome equals Approved
set content approval status in current item to approved
then Set Variable:strOutcome to Approved
else
set content approval status in current item to Rejected
then Set Variable:strOutcome to Rejected
Set workflow status to strOutcome
Then email workflow content:initiator
Transition to Stage
go to End of Workflow
Permalink
Hi Zied,
Could you please confirm which InfoPath DLL files need to be backed up?
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\Policy*InfoPath*.dll
or
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.Office.InfoPath
Thank you.
Permalink
Stefan,
We have not finish migration yet and we are facing below path issue to publish the form. All forms are disabled. Patches are installed but not run ps config yet. Any work around solution:
InfoPath cannot connect to the server. The server may be offline, your computer might not be connected to the network, or InfoPath Forms Services might not be enabled on the server. To fix this problem, start by checking your network connection, and then trying again.
Permalink
SharePoint Server: New-SPWeb with STS#0 fails during Team Site provisioning after recent patch
Hi,
I’ve encountered an issue with Team Site creation using
New-SPWebfollowing the latest SharePoint patching.Before applying the recent patch, I was able to create a standard Team Site using the following simple PowerShell command:
New-SPWeb -Url "http://<farm>/sites/Test" -Template "STS#0"
No
-Nameparameter was specified.After patching, the exact same command now fails during the application of the
STS#0template.The ULS log shows the following sequence:
Applying Template STS#0Feature Activation: Activating Feature 'Document Library Instance'
...
Failed to activate Site Scoped features for template STS#0
The associated exception is:
Exception attempting to ApplyWebTemplate to SPWeb http://<farm>/sites/TestMicrosoft.SharePoint.SPException:
Operation is not valid due to the current state of the object
--> System.Runtime.InteropServices.COMException
The issue appears to occur specifically during
ApplyWebTemplate, while SharePoint is activating the site-scoped features for theSTS#0template.Reproduction
Using an existing site collection (where we normally multiple subsites are creating each month without issue).
Run:
New-SPWeb -Url “http:///sites/Test” -Template “STS#0”
The web creation starts successfully.
SharePoint begins applying the STS#0 template.
Provisioning reaches the Document Library Instance feature.
ApplyWebTemplate fails with:
Operation is not valid due to the current state of the object
The site is not successfully provisioned.
Scope of the issue
I’ve reproduced this behaviour on multiple environments.
SharePoint Server 2019 DEV
SharePoint Server 2019 TEST
SharePoint Server Subscription Edition DEV
In each case, the site creation worked before patching and subsequently failed after patching.
This makes me suspect a regression introduced by one of the recent SharePoint updates, although I have not yet established which specific update/component is responsible.
The farms were patched and the SharePoint Products Configuration Wizard was run afterward.
Has anyone else encountered this issue with New-SPWeb and STS#0 after the latest SharePoint updates?
In particular, I’m interested in whether anyone has seen the combination of:
ApplyWebTemplate
Document Library Instance
Operation is not valid due to the current state of the object
System.Runtime.InteropServices.COMException
Any known workaround or Microsoft acknowledgement of this issue would be appreciated.
Thanks.
Permalink
Hello Robert,
you are using New-SPWeb for creating a site collection? I never did that and hence I am a little surprised that such a thing ever worked. The error you are receiving shows that you have a problem with a site feature which I can completely understand, because you do not have a spSite object you are working on, but only a spWeb object. Using New-SPSite instead of New-SPWeb should fix your problem.
Best regards
Permalink
No. Maybe I haven’t worded that clearly but I’m just creating a subsite. Normal out-of-the-box team site (STS#0).
Regarding the site collections it’s not working in existing ones but I did create a brand new site collection a few hours ago and it did actually work there.
Permalink
Hi Robert,
For site creation, we’ve updated the environment by replacing the assembly version references from 15.0 to 16.0. With that change in place, site creation is now working as expected.
Thanks !!
Permalink
Hi,
could you please let me know how exactly you made this change? Specifically, where did you update the assembly version references from 15.0 to 16.0?
Permalink
Hi Chandu,
Could you please let me know exactly how you made this change? Specifically, where did you update the assembly version references from 15.0 to 16.0?
We have already identified the assemblies on site level using the script and successfully updated them on our side. After the update, the previous errors were resolved, except for one remaining issue.
The subsite itself is created successfully, but the process then fails during the ApplyTemplate step, after which the newly created site is deleted. Just before we get one remaining “Failed to load type ‘Microsoft.Office.DocumentManagement.Internal.DocIdHandler’ from assembly ‘Microsoft.Office.DocumentManagement, Version=14.0.0.0”
I’d like to understand exactly what you changed on your side so we can compare the changes and apply the same fix if needed.
Permalink
Hi Bostjan,
Hope you are Doing Great 🙂
This might help you.
$site = $null
try {
$site = Get-SPSite $url
$toDel = @($site.EventReceivers | Where-Object { $_.Assembly -like ‘*Version=15.0.0.0*’ })
foreach ($er in $toDel) {Write-Host "Deleting $($er.Class) $($er.Id)"
$er.Delete()
}
$remaining = $site.EventReceivers | Where-Object { $_.Assembly -like '*Version=15.0.0.0*' }
if ($remaining) {
Write-Host "STILL PRESENT:" -ForegroundColor Yellow
$remaining | Select-Object Type, Class, Id
} else {
Write-Host "No Version=15.0.0.0 receivers left." -ForegroundColor Green
}
}
catch {
Write-Host “FAILED $url : $($_.Exception.Message)” -ForegroundColor Red
}
NOTE: The screenshot cuts off after the closing brace of the catch block (line 26).
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
$ns = ‘http://schemas.microsoft.com/sharepoint/events’
$old = ‘Microsoft.Office.DocumentManagement, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’
$new = ‘Microsoft.Office.DocumentManagement, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’
$url = “***”
Write-Host “=========” -ForegroundColor Cyan
$site = $null
$root = $null
try {
$site = Get-SPSite $url
$root = $site.RootWeb
foreach ($ct in @($root.ContentTypes)) {$doc = $null
try { $doc = $ct.XmlDocuments[$ns] } catch { }
$xml = $ct.SchemaXml
if ((-not $doc -or $doc -notlike "*$old*") -and $xml -notlike "*$old*") { continue }
Write-Host "FIX $($ct.Name)"
$ct.ReadOnly = $false
if ($ct.Sealed) { $ct.Sealed = $false }
$ct.Update($false)
if ($doc -like "*$old*") {
$ct.XmlDocuments.Delete($ns)
$ct.XmlDocuments.Add($doc.Replace($old, $new))
} else {
$ct.SchemaXmlWithResourceTokens = $xml.Replace($old, $new)
}
$ct.Update($false)
}
$still = @()
foreach ($ct in $root.ContentTypes) {
$n = [regex]::Matches($ct.SchemaXml, [regex]::Escape($old)).Count
if ($n) { $still += "STILL $($ct.Name) $n" }
}
if ($still) {
$still | ForEach-Object { Write-Host $_ -ForegroundColor Yellow }
} else {
Write-Host "No Version=15.0.0.0 DocumentManagement refs left in root content types." -ForegroundColor Green
}
}
catch {
Write-Host “FAILED $url : $($_.Exception.Message)” -ForegroundColor Red
}
finally {
if ($root) { $root.Dispose() }
if ($site) { $site.Dispose() }
}
Thanks!!
Permalink
Thanks for sharing! 🙂
In the meantime, we actually came up with a similar solution on our side, following a similar approach. The Content-Type part was the biggest issue for us, so this confirms what we found as well.
Thanks again for sending this over!
Permalink
Hi everyone,
After installing the latest SharePoint Server Subscription Edition September CU, we are experiencing several issues in our environment.
Unable to Edit Web Parts
After the CU installation, we are unable to edit existing web parts on SharePoint pages. The page loads correctly, but when attempting to edit a web part, the edit functionality does not work as expected.
SharePoint 2010 Workflows Not Working
We are also experiencing issues with SharePoint 2010 workflows. Workflows that were previously working are no longer functioning after installing the September CU.
When trying to run or access the workflow, SharePoint displays the generic error message:
Sorry, something went wrong.
Permalink
Hi Alexandru,
do you mean editing the web parts in the browser?
Please have a look into the KB article for September CU. It highlights that the ToolPane feature is disabled by default and needs to be enabled using a PowerShell command.
Enable-SPToolPane
SP2010 Workflows which use InfoPath forms are experiencing issues after September 2026 CU. Engineering is involved here.
Cheers,
Stefan
Permalink
Thank you for your reply.
Indeed, I’m now able to edit pages after enabling the SPToolPane.
If I understand correctly, the SharePoint 2010 workflows were disabled after we installed the September CU. Which script should we use to enable the SharePoint 2010 workflows again?
Permalink
Hi Alex,
please check this article:
https://blog.stefan-gossner.com/2026/08/14/are-you-using-sp2010-or-sp2013-workflows-in-your-sharepoint-farms-this-post-is-for-you/
Cheers,
Stefan
Permalink
Hi Stefan,
Greetings of the Day !!
We’re using the default SharePoint 2010 publishing workflow, which relies on InfoPath forms, and those forms appear to be failing during execution.
Thanks!!
Regards,
Chandu
Permalink
Hi Stefan,
Can I confirm that by installing the September 2026 CU, custom InfoPath forms can no longer be rendered by users, and we will need to find an alternative solution to hiding fields/rules etc?
Thanks in advance,
Daniel
Permalink
Hi Daniel,
InfoPath Forms in SPSE support has ended with July 2026 CU:
https://learn.microsoft.com/en-us/sharepoint/what-s-new/what-s-deprecated-or-removed-from-sharepoint-server-subscription-edition#infopath-forms-services
Cheers,
Stefan
Permalink
Hi Stefan,
Does the creation of remote event receivers using CSOM without an AppIdentifier still require the debug flag that was published for the August CU?
Permalink
Hi Maurice,
the answer is yes – and this will not change. This is an intentional change introduced with a security fix.
Cheers,
Stefan
Permalink
Hi Maurice,
this is currently being investigated. We hope to have clarity shortly.
But as support for this feature has ended with July 2026 CU my suggestion would be to migrate to a different solution for forms.
Cheers,
Stefan
Permalink
Hello Stefan and all
After installing September Patch on SPSE Onprem, it is no longer possible to use Connect-Pnp.
I get error 403. Does anyone else have this issue?
Kind Regards
Kjell (like in sea-shell)
Permalink
Hi Kjell,
PNP is not from Microsoft.
For PNP related issues, please contact the developers of PNP directly.
Cheers,
Stefan
Permalink
Ok. Thanks for reply.
I also get 403 on our workflows. The workflows are not created with 2010 or 2013, but are CSOM-apps. Can this be related to that I downloaded the patch too soon (9/9)?
Permalink
Hi Kjell,
which version number do you see for the installed fix in central administration patch status page?
Cheers,
Stefan
Permalink
I have 16.0.20326.20136 in CentralAdmin
Permalink
Hi Stefan,
After deploying the September CU, we have encountered an issue with term-driven navigation.
When we create a new publishing page, the page is crawled successfully, and both the content and title are searchable. However, the following managed properties are empty in the search index:
Tags = empty
owstaxidNavigation = empty
Path = physical .aspx URL
For older pages, these properties are populated correctly:
Tags = L0|#0…|Aktuelt
owstaxidNavigation = …|Aktuelt
Path = https://domain.no/aktuelt/digresources
As a result, the new pages are not included in the term-driven navigation, although they can be found through search.
Have you seen this issue before, or are there any known changes in the September CU that could affect the indexing of navigation terms for newly created publishing pages?
Regards,
Rune
Denne versjonen gjør problemet tydeligere og øker sannsynligheten for at Stefan raskt forstår at feilen ser ut til å være knyttet til taksonomi-/navigasjonsfeltene som ikke blir indeksert på nye publiseringssider etter CU-oppgraderingen.
Permalink
Good news: Microsoft is planning to release a new patch in the next few days to fix the InfoPath issue affecting SharePoint workflows 2010
Permalink
Do you have a source for this? Thank you!
Permalink
Where did you get this info from? Could you please kindly share a link to this announcement?
Permalink
Same question here, did you get this info from a MS Support Case
Permalink
Workflow Issue with this CU: The workflow does not start automatically
https://learn.microsoft.com/en-us/answers/questions/6004356/sharepoint-se-kb5002908-the-workflow-does-not-star?comment=question&translated=false#newest-question-comment
TLDR:
After migrations from SP2013 to SE Event Receiver bindings, Version=15.0.0.0 does not work anymore.
Permalink
Thanks, Thomas, updating Event Receivers from Version 15 to Version 16 does the trick 🙂🙌🙏
Permalink
Hi Stefan, I hope you’re doing well!
We’re having an issue with RemoteEventReceivers in connection with the current patch; they’re no longer working in our environment. It appears that Microsoft has introduced additional outbound security checks with these security patch.
The RemoteEventReceiver still triggers, but then aborts with an error message:
“failed outbound safety validation“: for example:
w3wp.exe (0x28EC) 0x2BD0 SharePoint Foundation General 35ec7 Unexpected Outbound request blocked: host ‘###.qa-apps.####.###’ is not in SPAllowedOutboundHosts farm property. URI: https://###.qa-apps.####.###/Services/DataRemoteEventReceiver.svc. Please contact farm admin to allow this host. c38d3ba2-694e-20bb-1a0e-740b7c36ba78
w3wp.exe (0x28EC) 0x2BD0 SharePoint Foundation Dev Events 35clt Medium Remote event receiver URL ‘https://###.qa-apps.####.###/Services/DataRemoteEventReceiver.svc’ failed outbound safety validation: Outbound request blocked. Host ‘####.qa-apps.####.###’ is not in SPAllowedOutboundHosts farm property. Please contact farm admin to allow this host. c38d3ba2-694e-20bb-1a0e-740b7c36ba78
I tried to add the host to the “WebApplication.properties”, but that didn’t have any effect.
Where and how do I need to set this “farm property” and the Url or host to allow the request again?
I hope you can help in this case!
Permalink
Hi Sören,
this is a farm property and not a web application property.
You can add the relevant hosts using this method:
PS C:> $farm = Get-SPFarm
PS C:> $farm.AddGenericAllowedListValue(“SPAllowedOutboundHosts”, “host1”)
PS C:> $farm.AddGenericAllowedListValue(“SPAllowedOutboundHosts”, “host2”)
PS C:> $farm.AddGenericAllowedListValue(“SPAllowedOutboundHosts”, “host3”)
PS C:> $farm.Update()
Cheers,
Stefan
Permalink
Hi Stefan,
We are seeing an issue after installing the September CU on SharePoint Server Subscription Edition.
All Nintex Forms Web Part test cases are failing in our SPSE September CU environments, while the same tests pass successfully in the August CU environments.
The issue is reproducible across multiple September CU farms, and we have verified that the SharePoint configuration and CU installation are correct.
One example failing test is:
Nintex.Forms.Tests.Testcases.WebPart.WebPartTests.DeleteListFormWebPartDisplayMode
Have you received any reports of Nintex List Form Web Parts or third-party Web Parts failing after the September CU? Are there any known Web Part-related changes or regressions in SPSE September CU that could explain this behavior?
Thanks.
Permalink
Hi Chitra,
please open a ticket with Nintex.
Microsoft is does not have any insights into the behavior of this product.
Cheers,
Stefan
Permalink
Hello Stefan,
Quick question: The commands to re-enable legacy workflows are also available in SharePoint 2016 following the previous CU, but I’m wondering how these functionalities will ultimately be disabled, given that SharePoint 2016 is no longer receiving updates.
Thank you.
Permalink
Having an issue where checking in edited display templates no longer updates their corresponding JavaScript files.
Permalink
After installing the September patch in non-prod, I am not able to complete a multiple step approval workflow. Simple workflows appear to work, like only sending an email. The failing workflow will complete the first approval step but will not advance to the next step. In the ULS log I am seeing this error:
LoadEventReceiverTypeSafe: Failed to load type ‘Microsoft.SharePoint.WorkflowServices.ContentSubscriptionEventReceiver’ from assembly ‘Microsoft.SharePoint.WorkflowServices, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’: Could not load file or assembly ‘Microsoft.SharePoint.WorkflowServices, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ or one of its dependencies. The system cannot find the file specified.
I also see that the this assembly was updated during the patch install.
Microsoft.SharePoint.WorkflowServices.dll is version 16.0.203326.20136
Is this a case were it needs to be registered somehow?
Permalink
Correction… I see the assembly but it is in a folder named: v4.0_16.0.0.0__71e9bce111e9429c
The log message appears to be looking for a match on Version=15.0.0.0.
Permalink
Is the same problem https://learn.microsoft.com/en-us/answers/questions/6004356/sharepoint-se-kb5002908-the-workflow-does-not-star?comment=question&translated=false#newest-question-comment
You must update the event receiver to the Version=16.0.0.0
Permalink
This did the trick. Thanks for helping me id the resolutions to this landmines.
Permalink
Hi Tom,
your site has event receiver registrations which references assemblies from SharePoint Server 2013.
Seems these references have not been updated during upgrade to SP2016.
To address this, you can use this script:
https://github.com/media-service-dev/sharepoint-powershell/blob/master/Update-EventReceiverVersionTo16.ps1
Cheers,
Stefan
Permalink
Hi Stefan,
I just patched my SharePoint Server SE farm with the September patch and now I am getting an error on Workflows.
When testing our workflows, we navigate to Workflow.asxp and click the button for the workflow. Is giving a popup error with the following text:
Error
The specified form template could not be found, or is not compatible with rendering in the browser. It might need to be republished as a browser-enabled form.
…
Though we have never setup or explicitly used InfoPath on our server, searches suggest that this may be InfoPath related and some AI sleuthing led me to find that it uses ($wf.InstantiationUrl) ~layouts/IniWrkflIP.aspx for these workflows, which supposedly uses InfoPath.
I see that InfoPath is no longer supported, so I suppose the break is related.
Any ideas of where to look next?
Permalink
Hi Greg,
a fix for this is currently in development.
Cheers,
Stefan
Permalink
Hello,
it is now well known that lots of people have been taken by suprise by the removal of InfoPath with this CU – we were aswell at some of our customer’s sites. Migrating the on-premises Infrastructure to Subscription Edition and staying on-premises was largely caused by the fact that there are lots of InfoPath Forms which will eventually be replaced by something else, but the mills of the gods grind slowly, Very slowly. Excruciatingly slowly.
Please do some lobbying inside Microsoft to quickly bring back InfoPath Forms, even as well-known-unsupported Feature – maybe even with a banner when the Web Forms load – multiple of our customers are still relying on this, paths for migrations are set, but will take months to years to complete.
Permalink
Hi Thomas,
a fix is currently being implemented to address this issue.
Cheers,
Stefan
Permalink
thank you
Permalink
Why did this “fix” break assembly policy redirects for event receivers? Is this “unsafe” functionality? Which CVE was it fixing? No information about any of that, just not working event receivers, because “security”….
Fortunately there’s workaround with:
$farm = Get-SPFarm
$farm.ServerDebugFlags.Add(59025)
$farm.update()
iisreset
Permalink
Hi Mark,
Thanks very much for posting this. I had 2 DEV environments and a TEST environment all with the same issue where I couldn’t create sites due to this assembly redirect stuff affecting event receivers and whatever else.
This has fixed my issue.
Regards,
Rob
Permalink
Hi there,
After I installed the CU, I’m no longer able to open any website. I get the following message:
Server Error:
http://go.microsoft.com/fwlink?LinkID=177673
Even when I create a new web application, a new site collection, and a new content database through the GUI (Central Administration), I still get the same error message.
Windows Server 2025 24H2 OS.BUILD 26100.33438
SharePoint SE OnPrem 16.0.20326.20136
In /_admin/FarmServers.aspx, all servers show “No action required”, as does /_admin/DatabaseStatus.aspx.
Any idea where i should looking for ?
Permalink
Hi Pedro,
please check the ULS log for relevant information – this error message is to generic to provide useful guidance.
Cheers,
Stefan
Permalink
Hi,
We have a solution that heavily depends on assembly redirects. Our current version is 8.0.0.0, and we redirect both 6.0.0.0 and 7.0.0.0 to 8.0.0.0. After installing the September 2026 CU, our custom assembly redirects no longer work, and we see the following error in ULS:
LoadEventReceiverTypeSafe: Failed to load type ‘xxx’ from assembly ‘yyy’: Could not load file or assembly ‘yyy, Version=7.0.0.0, Culture=neutral, PublicKeyToken=zzz’ or one of its dependencies. The system cannot find the file specified.
As a result, no custom event receivers are fired. Prior to this CU, this approach worked fine.
We haven’t seen any prior notice that this assembly redirection feature would stop working, and we consider it a significant breaking change. Could we have missed something in the release notes? This issue is impacting our clients quite severely, as it prevents the installation of SP CU in production environments.
We’ve tried the approach suggested in this post ($farm.AddGenericAllowedListValue), but it didn’t help.
Currently, the only workaround we’re aware of is iterating through all SharePoint objects to adjust the event receiver definition (as described in this link). However, we honestly see that as more of a workaround than a proper fix for what seems like a regression in the assembly redirection feature (or lack of communication about feature retirement). For very large environments like our clients’, this process is lengthy and leaves solutions non-functional for a significant period.
Is there maybe a way to mark the assemblies as safe to make the mechanism work again? Has anyone else experienced these issues with custom event receivers?
Thank you in advance for your help!
Best regards,
Maciej
Permalink
Hi Maciej,
similar problems have been reported by other customers – even for SharePoints own event receivers which were registered with an older SharePoint version.
E.g. here:
https://blog.stefan-gossner.com/2026/09/09/september-2026-cu-for-sharepoint-server-subscription-edition-is-available-for-download/#comment-89746
Currently the only solution is to update the event receiver registration using a PowerShell script similar to this approach:
https://blog.stefan-gossner.com/2026/09/09/september-2026-cu-for-sharepoint-server-subscription-edition-is-available-for-download/#comment-89841
Cheers,
Stefan
Permalink
I see a lot of comments about workflows. We use Nintex on prem subscription edition. After installing the SEP 2026 CU we have found that we can not update and publish workflows. The error message is:
soap:ServerServer was unable to process request. —> Failed to publish workflow:
Will the workflow fix being worked on by Microsoft also resolve this issue?
Permalink
for some reason I did not get the entire error message posted. Here it is:
soap:ServerServer was unable to process request. —> Failed to publish workflow:
Permalink
alright… it must be because its in greater than, less than notations. The error is: DeclarativeWorkflowDisabled
Permalink
Hi Bob,
we also use Nintex onPrem and we are not experiencing any issues after the September CU. Maybe you have some disabled some actions in the CA and the workflow can therefore not be published.
BR Alex
Permalink
Hi Bob,
The answer is no.
Support for SharePoint 2010-style workflows ended on July 14, 2026, and the functionality was further restricted with the September 2026 CU.
While existing SharePoint 2010 workflows can still be enabled through PowerShell, publishing new SharePoint 2010 workflows has been permanently disabled.
Customers should also be aware that support for SharePoint 2010 workflows is being phased out, and the remaining functionality is expected to be removed from the product in a future cumulative update.
Microsoft announced the end of support for SharePoint 2010 workflows back in 2021, providing a five-year transition period for customers to move to alternative workflow platforms.
The expectation was that this would provide sufficient time to migrate to supported solutions such as SharePoint 2013 workflows, Power Automate, or third-party workflow products.
Organizations that still depend on SharePoint 2010 workflows should prioritize the removal of these dependencies and accelerate migration planning.
Given the current direction of the product, it is strongly recommended to complete this transition as soon as possible.
Cheers,
Stefan
Permalink
We’ve installed the Sept 2026 CU (last applied CU was July 2026). Everything installed fine. Central Admin’s “Check Upgrade Status” and “Check Product and Patch Installation” confirm the CU has been successfully applied.
However, when the following is executed on our two server farm…
PS C:\Windows\system32> hostname
SERVER01
PS C:\Windows\system32> Get-SPServer | Select Name,NeedsUpgrade
Name NeedsUpgrade
—- ————
SERVER02 True
SERVER01 False
PS C:\Windows\system32> hostname
SERVER02
PS C:\Windows\system32> Get-SPServer | Select Name,NeedsUpgrade
Name NeedsUpgrade
—- ————
SERVER02 False
SERVER01 True
But I can’t find any other reports of people having the same issue.
Permalink
Hi Gary,
it seems there is a problem syncing the configuration database information to the specific servers.
My suggestion would be to clear the config cache:
Navigate to the following folder: %SystemDrive%\ProgramData\Microsoft\SharePoint\Config
Locate the folder that has a GUID as a name, such as a326e515-0047-4328-832c-02927b84d98c and open this directory.
On both servers delete all files EXCEPT the Cache.ini file. (DO NOT DELETE THIS FILE)
The folder should now only have the Cache.ini file.
Modify the Cache.ini file by right-clicking and selecting Open With > Notepad
Delete the contents of the Cache.ini file (example: 268861346) and replace it with 1.
Save and exit the Cache.ini file
This will ensure that the configuration data is forced to repopulate to the current server.
Cheers,
Stefan
Permalink
I’m curious if the bump from 16.0.19725.x to 16.0.20326.x indicates that we’re now at 26H2? Or could that come later this year with another bump?
Permalink
Hi Michael,
no that is not correct. The forks are not mapped to the feature updates.
26H1 was also not in line with the version jump from 16.0.19127.* to 16.0.19725.*
Cheers,
Stefan
Permalink
Gotcha. Thanks for the clarification.
Permalink
Getting a strange one, Farm is on August 2026 CU. Account has securityadmin and db_owner of all databases. Never had issues running PSConfig as currently set up. Looks to be happening on a Secure Store database.
Exception: User does not have permission to perform this action. You do not have permission to run the RECONFIGURE statement. User does not have permission to perform this action. You do not have permission to run the RECONFIGURE statement.
Online suggestion,
add “GRANT ALTER SETTINGS TO [domain\Setup];” or sysadmin.
Complete PSConfig.
remove “GRANT ALTER SETTINGS TO [domain\Setup];” or sysadmin.
If anyone has any insight or seen this one before that would be helpful.
Thanks, Matt
Permalink
I have now 4 independent farms with SharePoint SE on September 2026 CU, and in all of them Document Libraries are missing “Check-In” menu option in modern list view. You can create document or upload one, and do Check-Out, but then there is no “Check-In” option, only “Undo Check-Out” option. In classic library view the Check-In shows just fine. Is it just me?
Permalink
Hi Stefan,
We recently patched our SharePoint SE environment with the Sept 2026 patch and unfortunately it broke a 3rd party tool (Aderant Handshake List Guru Mirroring). We are seeing the following error:
LoadEventReceiverTypeSafe: Failed to load type ‘HSListGuru.ListMirrorEventHandler’ from assembly ‘HSListGuru, Version=1.0.0.1, Culture=neutral, PublicKeyToken=8d34f80be45307bf’: Cannot resolve dependency to assembly ‘Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event. ba723ea2-101c-5019-cfb2-0ae0049705d9
We are in communication with the vendor as I would think this would require the List Guru tool to be recompiled and reinstalled to use version 16.0.0.0 instead of 12.0.0.0, but I wanted to check if you had any other ideas or tricks on the SharePoint side we could try on the server itself to allow this tool to proceed post Sept 2026 patch.
Thank you!
Permalink
Hi Pat,
I’ve also a similar problem regarding a 3rd party event receiver that references “‘Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’” itself and get the exactly same error message. Tried all possible workaround (safe control, binding redirect, disabling propertraversal, etc.) – no solution found until now.
Permalink
Hi Oliver,
seems your site has event receiver registrations from SharePoint Server 2010 which did not get updated during upgrade to SP2013 and 2016.
Please use this script:
https://github.com/media-service-dev/sharepoint-powershell/blob/master/Update-EventReceiverVersionTo16.ps1
Be aware that this script fixes the registrations from SP2013 with version 15.0.0.0. In your case you need to replace 15.0.0.0 in $oldAssembly with 14.0.0.0.
Cheers,
Stefan
Permalink
Hi Stefan,
Do you think this fix would work for our issue as well?
Thanks!
Pat
Permalink
Hi Pat,
yes – but here these are 3rd party dlls and you need to check the required signature yourself or with the vendor.
Cheers,
Stefan
Permalink
Hi Stefan,
thanks for your valuable feedback and response – but in my case your workaround is not really a viable option as the assembly that is registered inside the EventReceiver Properties of the List/Library references the 3rd party DLL and not the SharePoint DLL. Therefore, if this “drop” of older Microsoft.Sharepoint DLLs is intended with September CU 2026, I am really out of luck with changing the reference (as the 3rd party library has not been change/published the last 10 years from the vendor) -> morealess Microsoft dropped this “backward” compatibility with this update and a lot of 3rd party components have to be recompiled using the most recent SharePoint DLLs.
Greetings,
Oliver
Permalink
Hi Oliver,
in this case try this solution:
$farm = Get-SPFarm
$farm.AddGenericAllowedListValue(“AllowedDLCAssemblies”, “assembly, Version=x.0.0.0, Culture=neutral, PublicKeyToken=xxxx”)
$farm.Update()
Update the second string to match the 3rd party assembly.
Cheers,
Stefan
Permalink
Hi Stefan,
just tried your solution – no effect at all – eventreceiver is firing and following error message occurs in ULS:
LoadEventReceiverTypeSafe: Failed to load type ‘Assembly.Type’ from assembly ‘Assembly, Version=x.y.0.0, Culture=neutral, PublicKeyToken=xxxx: Die Abhängigkeit von Assembly “Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” kann nicht aufgelöst werden, da sie nicht vorher geladen wurde. Beim Verwenden der ReflectionOnly-APIs müssen abhängige Assemblys vorher geladen oder über das ReflectionOnlyAssemblyResolve-Ereignis bei Bedarf geladen werden.
Greetings,
Oliver
Permalink
Hi Oliver,
I see – the issue is not in the assembly registration in SharePoint.
From the message it seems the event registration registers a 3rd party assembly which you obfuscated above.
And this assembly has a built in reference to the SharePoint 2010 version of the Microsoft.SharePoint.dll with version 14.0.0.0
It seems this 3rd party event receiver was originally built for SP2010. An updated version of this dll which references the SPSE version of the DLL should help.
Cheers,
Stefan
Permalink
Hi Stefan,
FYI in case this helps anyone else troubleshooting PSConfig after the September 2026 CU for SharePoint Server Subscription Edition, build
16.0.20326.20136.We had PSConfig fail during:
applicationcontent -install
The PSConfig diagnostics showed:
System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.SharePoint.Administration.SPAspConfigurationFile.ApplyActionToXmlDocument(...)
at Microsoft.SharePoint.Administration.SPAspConfigurationFile.MergeWebConfig(...)
In ULS, the failure occurred while merging local IIS virtual directory
web.configfiles. The last visible action was from:C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\config\webconfig.ipfs.xml
In our case, the affected web.config files had partial InfoPath merge state:
InfoPath SafeControls were present.
The first IPFS
MergedActionsmarker was present.The
InfoPathDeprecationmodule entries were missing from bothsystem.web/httpModulesandsystem.webServer/modules.The later two IPFS
MergedActionsmarkers were missing.After adding the missing
InfoPathDeprecationmodule entries and the missingMergedActionsmarkers on all affected SharePoint servers/web.config files, PSConfig completed successfully.This looked like local web.config drift or a previous partial merge state exposed by the CU, not necessarily a bad CU package. The difficult part was that PSConfig only reported a generic
NullReferenceExceptionfromMergeWebConfig, so the actual clue was in ULS around the lastwebconfig.ipfs.xmlaction.Hope this helps someone searching for the same symptom.
Permalink
Hello Stefan!
Since installing September CU we have an issue with uploading apps to the App Catalog.
“Product ID”, “Title” and “Metadata Language” is not read correctly when app package is uploaded.
We can see same behavior in three different farms that has same patch level.
Anything you have heard about?
Kind regards
/Fredrik
Permalink
I can this in ULS log:
LoadEventReceiverTypeSafe: Failed to load type ‘Microsoft.SharePoint.Marketplace.CorporateCuratedGallery.SPCorporateCatalogEventReceiver’ from assembly ‘Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’: Could not load file or assembly ‘Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ or one of its dependencies. The system cannot find the file specified.
Permalink
Hi Frederik,
it seems your site has event receiver registrations which references assemblies from SharePoint Server 2013.
Seems these references have not been updated during upgrade to SP2016.
To address this, you can use this script:
https://github.com/media-service-dev/sharepoint-powershell/blob/master/Update-EventReceiverVersionTo16.ps1
Cheers,
Stefan
Permalink
Thanks Stefan! Will try.
Permalink
Sorry to say but same error occurs in the ULS log even after running the proposed event receiver update script.
Permalink
Hi Frederik,
in this case, my suggestion would be to open a ticket with Microsoft Support to ensure that this is analyzed in more details.
Cheers,
Stefan
Permalink
Hi Stefan,
We recently successfully patched our UAT SharePoint environment with the September 2026 update (KB5002908).
Following the patch, some users have encountered issues when attempting to upload new files or replace existing files using the Modern Experience view.
The affected users have performed several troubleshooting attempts, including:
– Retrying the upload multiple times
– Uploading different files
– Uploading to different folders
– Deleting and re-uploading the files
However, the issue persists.
As an additional test, we renamed one of the files and were then able to upload it successfully. However, this would not be a practical long-term workaround, as it would result in duplicate sets of files with different naming conventions.
The users also confirmed that the same files can be successfully uploaded or replaced when using the Classic view. The issue therefore appears to be specific to the Modern Experience view.
We encountered a similar scenario sometime between April and June 2025. However, despite an extended period of troubleshooting with Microsoft, no resolution was identified at the time.
Hopefully, you may have some insights into this issue or be able to advise on any possible causes or troubleshooting steps we could explore.
Thank you.
Permalink
Hi Stefan,
In case you missed this, any advise?
Thank you.
Permalink
Hi Justin,
please open a support case with Microsoft to get this analyzed.
Thanks,
Stefan
Permalink
Hi, I’m also trying to apply the September 2026 patch to my SharePoint SE test environment, and I’m currently testing my Nintex workflow. After following the instructions below:
https://community.nintex.com/nintex%2Dfor%2Dsharepoint%2D67/workflow%2Dfails%2Dto%2Drun%2Dafter%2Dapplying%2Dseptember%2D2026%2Dcu%2Dupdate%2Dsubscription%2Dedition%2D74205
the workflow is now able to run, but I’m getting the following error when the action goes to send email like that :
9/30/2026 10:54 AM – Comment – Failed to send notification. Access denied.
Could you please advise what needs to be done to resolve this issue?
Thank you.
Permalink
Hi Hafid,
if this is part of a Nintex operation, please open a ticket with Nintex as Microsoft does not support this and does not know how Nintex workflow actions work internally.
Cheers,
Stefan
Permalink
Hi Stefan,
Just a question regarding:
Notifies that the ToolPane feature will be disabled starting with the September 2026 Cumulative Update. To enable the feature for a site collection, use the Enable- SPToolPane cmdlet. To disable the feature, use the Disable- SPToolPane cmdlet. To view all site collections for which the feature is enabled, use the Get- SPToolPaneEnabledSites cmdlet.
Why is Microsoft doing this? this means if it’s not enable, users cannot edit or add new webparts to pages. And can this only be done through powershell? Why not in a web app property instead of a site collections. Dozen site collections are being created and now we have to find new ways of adding this script to newly created site collections. It just doesn’t make sense that the toolpane is default disabled.
Permalink
Hi Peter,
this is just the first step of a broader defense-in-depth initiative. The plan is to disable several features by default that are not required by all customers, while still providing the option to re-enable them when needed.
The goal of this strategy is to significantly reduce the potential attack surface of SharePoint Server farms.
That said, there is currently no known threat vector associated with any of the features that will be disabled by default going forward.
The decision to allow configuration at both the web application and site collection level for the ToolPane provides greater flexibility and a more granular approach. For example, a web application may contain classic sites that rely on web parts, alongside sites that do not use web parts and newer sites that leverage the modern UI. In such scenarios, it makes sense to keep the feature disabled on most sites and enable it only where the Tool Pane is actually required.
Cheers,
Stefan
Permalink
Thx Stefan for the clarification. Good to have some insights in this
Permalink
Hi Stefan,
since September CU we have noticed this message in Health Analyzer:
Remote event receivers without application identity are detected on one or more site collections
With the content:
One or more remote event receivers were registered without an application identity and may bypass item-level permissions, posing a security risk. Starting with the November Public Update, these receivers will be disabled by default. Use Get-SPOrphanedRemoteEventReceiver to identify them. Remove unauthorized receivers or update them with a valid application identity.
All these findings (got from Get-SPOrphanedRemoteEventReceiver) are WebHooks and seems to be affected because of the “ReceiverName” from that output is allways “Microsoft.SharePoint.Webhooks.SPWebhookItemEventReceiver”
Since there is no known way for us to assign an Application to a WebHook, do we need to be worried about this message or will be there a farm property to bypass the deactivation?
Thank and best regards,
Christian
Permalink
Hi Christian,
yes, you should be concerned. Based on the current communication all remote event receivers without a mapped application identify will be blocked with November CU.
As your specific web hook is flagged there is a good chance that it might be blocked as well.
I would recommend to open a ticket with Microsoft support to get clarity on this.
Cheers,
Stefan
Permalink
Hi Stefan,
We are seeing a reproducible upgrade failure after installing September 2026 CU (16.0.20326.20136) on SPSE.
PSCONFIG fails during:
SearchAdminDatabaseSequence.PostUpgrade()
SearchDatabaseRoleManager.UpdateSearchRolesForDatabase()
SearchDatabaseRoleManager.AddPermissionsToRole()
with hundreds of errors like:
Cannot find the object ‘proc_MSS_QLog_SetCleanupDays’,
because it does not exist or you do not have permission.
However, we have verified that:
all reported proc_MSS_* procedures actually exist
all are located in schema dbo
Search Service Application is Online
all Search components are Active
farm account is member of SPSearchDBAdmin
SQL Server is SQL 2022 RTM (16.0.1000.6)
The upgrade log also shows:
UserDefinedModules already parsed. Found 618 objects, immediately before the failure, which suggests SharePoint successfully discovers the objects before reporting them as missing.
We also corrected an orphaned database owner and tested PSCONFIG using both the farm account and the setup account with identical results.
Have you seen anything similar with the September 2026 CU or Search Admin Database upgrades where AddPermissionsToRole() reports existing proc_MSS_* objects as missing?
Permalink
Hi Gustav,
please open a ticket with Microsoft Support to ensure this can be investigated.
Cheers,
Stefan
Permalink
Hi Stefan,
I found another issue. In a SharePoint SE environment with CU september installed, I’m trying to create a subsite of the type ‘Publishing’. While creating the site It errors out with errors in de uls viewer:
LoadEventReceiverTypeSafe: Failed to load type ‘Microsoft.Office.DocumentManagement.DocumentSets.DocumentSetEventReceiver’ from assembly ‘Microsoft.Office.DocumentManagement, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’: Could not load file or assembly ‘Microsoft.Office.DocumentManagement, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ or one of its dependencies. The system cannot find the file specified.
These are out of the box Microsoft templates, no custom template which break. This looks like de 15 -> 16 bug but this is not on existing sites, it appears when creating new publishing sites.
Is this something Microsoft is going to fix?
Permalink
Hi Peter,
ensure to open a ticket with Microsoft Support to ensure this is properly reported and gets addressed.
Cheers,
Stefan