The product group released the September 2020 Cumulative Update for SharePoint Server 2016 product family.
This CU also includes Feature Pack 1 which was released with December 2016 CU and Feature Pack 2 which was released with September 2017 CU.
The KB articles for September 2020 CU are available here:
- KB 4484506 – September 2020 Update for SharePoint Server 2016 (language independent) – This is also a security update!
- KB 4484512 – September 2020 Update for SharePoint Server 2016 (language dependent) – This is also a security update!
The download for September 2020 CU is available here:
- Download September 2020 Update for SharePoint Server 2016 (language independent) – This is also a security update!
- Download September 2020 Update for SharePoint Server 2016 (language dependent) – This is also a security update!
Important: It is required to install both fixes (language dependent and independent) to fully patch a SharePoint server. This applies also to servers which do not have language packs installed. The reason is that each SharePoint installation includes a language dependent component together with a language independent component. If additional language packs are added later (only) the language dependent fix has to be applied again.
It is irrelevant which language you pick on the drop down in download center. Even the language dependent fixes are all in the same package for all languages.
After installing the fixes you need to run the SharePoint 2016 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.
SharePoint 2016 September 2020 CU Build Numbers:
Language independent fix: 16.0.5056.1001
Language dependent fix: 16.0.5056.1000
To understand the different version numbers please have a look at my article which explains the different SharePoint build numbers.
Please ensure to have a look at the SharePoint Patching Best Practices before applying new fixes.
Related Links:
- Technet: Updated Product Servicing Policy for SharePoint Server 2016
- Blog: SharePoint Patching Best Practices
- Blog: Common Question: What is the difference between a PU, a CU and a COD?
- Blog: SharePoint Patching demystified
- Blog: Why I prefer PSCONFIGUI.EXE over PSCONFIG.EXE
- Technet: Update Center for Microsoft Office, Office Servers, and Related Products
- Blog: SharePoint Server 2016 Patch Build Numbers Powershell Module
- Blog: SharePoint Server 2016 Zero-Downtime Patching Demystified
- Blog: SharePoint does not have a build version. Full Stop.
Permalink
Dear Stephan Gossner,
The link on MS support page for kb4484506 to Download Center doesn’t work. The link returns with error message “We’re sorry, this download is no longer available. “
Permalink
Hi Lajos,
thanks for the info! I have double checked and it is indeed broken at the moment.
I have reported it to the relevant team to get this fixed.
Cheers,
Stefan
Permalink
Hi Lajos,
please try this link. The KB article should be updated in a couple of hours.
https://www.microsoft.com/en-us/download/details.aspx?id=102105
Thanks,
Stefan
Permalink
Dear Stefan,
it works
thank you for fast help.
br,
Lajos
Permalink
Hi Stefan,
the CU 2020-08 for SharePoint 2013 contains the known issue with web parts causing page errors: KB4572409 https://support.microsoft.com/en-us/help/4572409/sharepoint-pages-not-render-when-using-unsafe-controls. We do experience very comparable behaviour on SharePoint 2016.
Is it intentional that this change affects SP2016 in addition to the listed SP2010/SP2013 in KB4572409? And is this change to be considered permanent? I presume the answer is “yes” to both?
Thank you and best regards,
Adrian
Permalink
Hi Adrian,
I received an update from the relevant people in our product group: the code change in SP2010 and SP2013 is different from the code change in SP2016 and SP2019.
SP2016 and SP2019 should not be affected by the same issue and thats the reason that the KB article only lists SP2010 and SP2013.
If you see the issue on SP2016 then please open a ticket with Microsoft support to ensure that this can be analyzed in more detail.
Thanks,
Stefan
Permalink
Hi, Stefan, I’m seeing the issue in my 2016 DEV environment. So it’s there, for sure.
Permalink
Hi Radek, please ensure to open a ticket to ensure that this is tracked and can be analyzed in more details.
Permalink
Hi Stefan, I would like to open the ticket but have no support plan. I’m just a normal developer knowing that dealing with SharePoint related tickets is like teaching parrots to talk. If there is a way to open the ticket for free, I can do it. Otherwise, I’m sorry…
Permalink
I updated our SharePoint 2016 servers with June 2020 CU. Is September 2020 CU critical one and do I need to update it? Or can I wait and do Dec 20 update?
Permalink
Hi Kala,
please have a look at the Kb articles for this CU.
It includes references for each CVE for each security fix included which allows you to decide that based on your business requirements.
Cheers,
Stefan
Permalink
I am also getting similar behavior on SP2016 with “The type could not be found or it is not registered as safe”. This is across all my site collections. We have custom solutions and master pages, however this is specifically complaining about a type that has never required a safe control entry. Even after manually adding a safe control in the web.config it continues to error out. It is as though SharePoint can no longer find the assemblies in the GAC even though they exist.
I went as far as adding the ControlCompatMode=”true” attribute as stated in the workaround in KB4572409 and still no good. I will most likely be opening a case with Microsoft Monday morning.
Permalink
Hi Stefan, we’re meeting this issue after applying the Sep 2020 CU.
The base type ‘OurCustom.Branding.GenericPageLayout’ is not allowed for this page. The type OurCustom.Branding.GenericPageLayout, OurCustom.Branding, Version=1.0.0.0, Culture=neutral, PublicKeyToken=80842254f7ccc26f could not be found or it is not registered as safe.
Comparing the web.config files between both Aug and Sep, the only (added) differences are as follows:
Sep:
Aug:
Sep:
Sep:
Permalink
Hi Desmond,
seems some content is missing in your comment.
Cheers,
Stefan
Permalink
I think they were stripped out by the comment system. I’ve already opened a support case. Do you mind taking a look at it please? 21842067. Thank you.
Permalink
Update: after putting in the correct safecontrol entry (which I didn’t need before the SP2016 Sept. patches) I was presented with a new error saying code blocks are not allowed in this file. It was referring to my master page. Putting an entry in the web.config allows my site to render correctly.
Again, this all worked before the patches without the need of a workaround. I will still be opening a case with Microsoft tomorrow.
Cheers!
Tom
Permalink
Hi Stefan,
How would I determine if the web part errors would determine our 2016 environment? Is this mainly if you are running custom controls for ASP.net?
Thanks,
Jess
Permalink
Hi Jess,
from my understanding it would affect ghosted pages/page layouts/master pages which include inline code and custom controls which are not registered as safe controls in the web.config.
Cheers,
Stefan
Permalink
Hi Stefan,
After installing September 2020 SP patches, none of the farms show upgrade available option. Is there a known issue about this?
Permalink
Just wanted to pass along something that had worked for me, as I too had the unsafe controls issue at a client site after running this update. When adding lines to the web.config, the vendor of web parts had been supplying lines via solution deployment as that had TypeName=”*”. To fix this, I had to be more specific and give the faulting typeName instead of the wildcard.
Doesn’t appear that I can post the actual line here, so parameters that worked for me were:
Assembly = Vendor.Portal.Runtime (removed vendor name, and this is the name of the DLL from the GAC)
Namespace = Vendor.Portal.Runtime (removed vendor name, and this is the name of the DLL from the GAC)
TypeName = SharePoint.Redirect (the actual faulting BaseType from error message without the Assembly prefixed)
I’ll also note that no line for this control was previously in their web.config prior to this update and solution has worked since 2013.
Permalink
Hi Jeremy,
We are getting this below error while we accessing the Search Service application from Central administration. So could you please suggest me the actual line which I needs to add under web.config.
Parser Error Message: The base type ‘Microsoft.Office.Server.Search.Internal.UI.SearchAdministration’ is not allowed for this page. The type Microsoft.Office.Server.Search.Internal.UI.SearchAdministration, Microsoft.Office.Server.Search, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c could not be found or it is not registered as safe.
Permalink
Hi Hariharan,
there should not be a need to change anything manually.
The message indicates that the SharePoint configuration wizard was not run after installing the CU.
The config wizard would adjust the web.config to resolves this issue.
Cheers,
Stefan
Permalink
Jeremy, your last message saved my life. Thank you!!!
Permalink
Hello Stefan,
the CU 2020-08 for SharePoint 2013 contains the known issue with web parts causing page blunders: KB4572409 https://support.microsoft.com/en-us/help/4572409/sharepoint-pages-not-render-when-utilizing dangerous controls. We do encounter entirely practically identical conduct on SharePoint 2016.
Is it purposeful that this change influences SP2016 notwithstanding the recorded SP2010/SP2013 in KB4572409? Also, is this change to be viewed as lasting? I assume the appropriate response is “yes” to both?
Much obliged to you and best respects
Permalink
Hi Martin,
I would suggest to have a look at the following article which should address your question:
https://blog.stefan-gossner.com/2020/09/25/trending-issue-after-installing-september-2020-cu-and-pu-custom-pages-and-controls-fail-to-render/
Cheers,
Stefan
Permalink
Hi Stefan,
We are getting this below error in our SP2016, Search Administration Page.. I am not sure is this occuring after this update or not. We have installed this update 3 weeks back. But we are noticing this error today only. Any clue on this.
Sorry, something went wrong
The base type ‘Microsoft.Office.Server.Search.Internal.UI.SearchAdministration’ is not allowed for this page. The type Microsoft.Office.Server.Search.Internal.UI.SearchAdministration, Microsoft.Office.Server.Search, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c could not be found or it is not registered as safe.
Thanks, Hari
Permalink
Hi Hari,
this error will occur if the SharePoint configuration wizard was not run after installing the CU.
The configuration wizard will update the web.config with the necessary changes.
Cheers,
Stefan
Permalink
Hi Stefan,
One of the known issue for kb4484506 is that SharePoint user is unable to access both Result Sources and Query Rules from Site Settings after the patching. I understand the workaround is to use PowerShell to manage them but there is very limited information about it especially to update existing Result Sources & Query Rules. Can you please shed any light on this?
Thanks, Michael
Permalink
Hello Stefan,
After installing the Sharepoint foundation fix of september, we were facing the issue following.
Custom master page is not rendering and getting the following error.
“could not be found or it is not registered as safe.”
I have tried this workaround to add the safecontrol entry in the web.config with the ControlCompatMode=”True”
as suggested in the following link:
https://support.microsoft.com/en-us/help/4572409/sharepoint-pages-not-render-when-using-unsafe-controls
Still issue persist.
Does this issue will get resolve in the october month path?
Could you please suggest to fix this issue.
Thanks,
Suri
Permalink
Hi Suri,
adding the relevant entries in the web.config is the solution – not a workaround.
The behavior is the new expected behavior and there will not be a “fix” to resolve it as this behavior is intentional.
If you need assistance to add the required entries to the web.config, please involve Microsoft support.
Cheers,
Stefan
Permalink
Hello Stefan,
Thanks for your confirmation as as a solution to add the entries.
As it is mentioned as not recommended, hence we would like to check with you on this.
We have added the relevant entries as below, still the issue persist.
sample entry:
Could you please advise.
Thanks,
Suri
Permalink
Hi Suri,
I cannot see the sample entries – they might have been removed by the comment system.
My recommendation would be to involve Microsoft Support if you need assistance.
Cheers,
Stefan
Permalink
Hi Stefan,
Please find the sample entry as below
SafeControl Assembly=”assemblyname, Version=1.0.0.0, Culture=neutral, PublicKeyToken=xxxxxxxxxxxxxx” Namespace=”namespace” TypeName=”*” Safe=”True” ControlCompatMode=”True”
Kindly confirm, if any attributes are missing.
Thanks for your support.
Thanks,
Suri
Permalink
Hi Suri,
the line itself looks good but it depends on the specific scenario as different settings might be required.
Please have a look here for all details:
https://blog.stefan-gossner.com/2020/09/25/trending-issue-after-installing-september-2020-cu-and-pu-custom-pages-and-controls-fail-to-render/
Thanks,
Stefan
Permalink
Hello Stefan,
It works after the safecontrol entry in the web.config.
Also, I would like to inform you that it is affecting only in Sharepoint Foundation version not in the standard edition.
Thanks,
Suri
Permalink
Hi Stefan,
Has Microsoft release a bug fix for September CU for SharePoint 2016?
Sincerely,
Anteneh
Permalink
Hi Anteneh,
for which issue exactly?
Thanks,
Stefan
Permalink
Hi Stefan,
Below are some of the links that I found about September CU. Has there been a bug fix?
https://blog.stefan-gossner.com/2020/09/25/trending-issue-after-installing-september-2020-cu-and-pu-custom-pages-and-controls-fail-to-render/
Permalink
Hi Anteneh,
there is a misunderstanding: This is not a bug. This is now by design. The design was changed to fix a security vulnerability. All custom code now has to be explicitly enabled in the web.config.
Cheers,
Stefan
Permalink
Hi Stefan, Thank you so much for your quick response.