September 2020 CU for SharePoint 2013 product family is available for download

- - 34 Comments

The product group released the September 2020 Cumulative Update for the SharePoint 2013 product family.

For September 2020 CU we have full server packages (also known as Uber packages) for all products. No other CU is required to fully patch SharePoint.

As this is a common question: Yes, September 2020 CU includes all fixes from September 2020 PU.

ATTENTION:

Be aware that all Updates for SharePoint 2013 require SharePoint Server 2013 SP1 to be installed first.

Please also have a look at the article that discusses how to properly patch a SharePoint 2013 farm which has Search enabled (see below).

Previous releases of the SharePoint Server 2013 cumulative update included both the executable and the .CAB file in the same self-extracting executable download. Because of the file size, the SharePoint Server 2013 package has been divided into several separate downloads. One contains the executable file, while the others contain the CAB file. All are necessary and must be placed in the same folder to successfully install the update. All are available by clicking the same Hotfix Download Available link in the KB article for the release.

This CU includes all SharePoint 2013 fixes (including all SharePoint 2013 security fixes) released since SP1. The CU does not include SP1. You need to install SP1 before installing this CU.

The KB articles for September 2020 CU should be available at the following locations in a couple of hours:

  • KB 4484519 – SharePoint Foundation 2013 September 2020 CU
  • KB 4484523 – SharePoint Server 2013 September 2020 CU
  • KB 4484521 – Project Server 2013 September 2020 CU
  • KB 4484518 – Office Web Apps Server 2013 September 2020 CU

The Full Server Packages for September 2020 CU are available through the following links:

After installing the fixes you need to run the SharePoint 2013 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.

Be aware that the SharePoint Server 2013 CU contains the SharePoint Foundation 2013 CU. And the Project Server 2013 CU also contains the SharePoint Server 2013 CU and SharePoint Foundation 2013 CU.

Please ensure to have a look at the SharePoint Patching Best Practices before applying new fixes.

Related Info:

34 Comments


  1. After installing SharePoint Server 2013 September 2020 CU, we get this:
    The base type ‘AC.Web.PageLayouts.ACPageLayouts.ACHomePage’ is not allowed for this page. The type AC.Web.PageLayouts.ACPageLayouts.ACHomePage, AC.Web, Version=1.0.0.0, Culture=en, PublicKeyToken=5f3d55c70580fe7d could not be found or it is not registered as safe.

    Reply

  2. Hi Stefan, we’re seeing this happen after applying Sep 2020 CU. The unsafe control fix doesn’t resolve the problem.

    Container WebPart: The attribute ‘autoeventwireup’ is not allowed in this page.
    at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseFile(String physicalPath, VirtualPath virtualPath) at System.Web.UI.TemplateParser.ParseInternal() at System.Web.UI.TemplateParser.Parse() at System.Web.Compilation.BaseTemplateBuildProvider.get_CodeCompilerType() at System.Web.Compilation.BuildProvider.GetCompilerTypeFromBuildProvider(BuildProvider buildProvider) at System.Web.Compilation.BuildProvidersCompiler.ProcessBuildProviders() at System.Web.Compilation.BuildProvidersCompiler.PerformBuild() at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVPathBuildResult(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean ensureIsUpToDate) at System.Web.UI.TemplateControl.LoadControl(VirtualPath virtualPath) at OurCustomFramework.WebParts.ContainerWebPart.CreateChildControls()

    Reply

    1. Hi Desmond,
      please open a ticket with Microsoft support to ensure that this issue is tracked and can be analyzed in more details.
      Thanks,
      Stefan

      Reply

  3. After installing September 2020 CU for SharePoint 2013 we have started seeing following errors in few of the custom web parts:

    Web Part Error: The control type ‘System.Data.DataTable’ is not allowed on this page. The type System.Data.DataTable, System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 could not be found or it is not registered as safe. Correlation ID: c206799f-10dd-7037-7d24-5086ce38d8a7.

    Reply

  4. Stefan,

    We are experiencing the following issue after the installation of this update:

    The base type ‘VSSP.PageLayouts.Templates.IntranetPageLayout’ is not allowed for this page. The type VSSP.PageLayouts.Templates.IntranetPageLayout, VSSP, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3499b5cce3f2192f could not be found or it is not registered as safe.

    The assembly is marked as safe in the code and we have made sure that we have added SafeControl entries in the web.config. We have even gone as far as adding the suggested workaround code to the web.config as described in this article:

    https://support.microsoft.com/en-us/help/4572409/sharepoint-pages-not-render-when-using-unsafe-controls

    The same error continues to persist and it did not appear before this installation. What else can we try?

    Reply

  5. Stefan,

    I’m sorry but I don’t think you read the rest of my original question. We have already attempted to apply the workaround suggested in the article and that had no effect. The error still persists.

    Reply

    1. Hi Eric,
      you are right – did not read your comment in all detail. Sorry for that.
      If the entry does not help, please open a support case with Microsoft to get this analyzed.
      Cheers,
      Stefan

      Reply

  6. Hi Stefan,

    We have noticed similar issues after deploying Sep’2020 CU, PublicKeyToken=1e621779d1cb1ec3 could not be found or it is not registered as safe.

    Regards
    Bimal

    Reply

  7. After installing September 2020 CU for SharePoint 2013, the Search result sources page is throwing an unexpected error.

    Reply

    1. Hi Preeti,
      you might want to open a ticket with Microsoft to get this analyzed.
      Cheers,
      Stefan

      Reply

  8. We had the same problem for the search results, searchfarmdashboard and searchadministration
    We added this line in each site’s webconfig in the safecontrols section :

    error message we had for the searchadministration :
    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=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c could not be found or it is not registered as safe.

    Le type de base « Microsoft.Office.Server.Search.Internal.UI.SearchResultsLayoutPage » n’est pas autorisé pour cette page. Le type Microsoft.Office.Server.Search.Internal.UI.SearchResultsLayoutPage, Microsoft.Office.Server.Search, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c est introuvable ou n’est pas inscrit comme fiable.

    Reply

    1. Hi Ben, did you run the config wizard after installing the fix? Because these lines are added when running it after installing the September fixes.

      Reply

      1. Hi Stefan,

        same issue here after the fix was installed. I cannot run the config wizard because it tells me that needed updates aren’t installed although they are installed. Get-SPProduct -local didn’t solve the issue. Any way to add the missing entries as quick fix to get Search Service Application to work again?

        Best regards,
        Markus

        Reply

        1. Hi Markus,
          please check on which machines the fixes are missing. They might be missing on a different machine than the one where you are running PSConfig.
          If the fixes are indeed installed on all machines and after you ran Get-SPProduct -local on all machines you should open a ticket with Microsoft Support to evaluate what is wrong.
          Cheers,
          Stefan

          Reply

  9. Can you give me any info on the config wizard. Getting the same error as the one in french up above.

    Reply

    1. Hi Daron,
      after every SharePoint fix installation you need to run the SharePoint Configuration Wizard which performs certain operations on the machine and in the database to finalize the fix installation.
      Cheers,
      Stefan

      Reply

  10. Hi Stefan,

    What if we have extreme volumes of data in content databases? Running SP Config will take some days to finish, so how can we mitigate the downtime if the content are huge?

    Thanks
    Satish

    Reply

    1. Hi Satish,
      for SP2013 we do not really have a solution.
      Best would be to switch to SP2016 or SP2019 where zero-downtime can be achieved during patching.
      Cheers,
      Stefan

      Reply

  12. This security patch is causing problems with CorasWorks. We applied a work around for some of the webparts that were not rendering. This is the fix we applied to the web.config. CorasWorks Chart is still a problem.

    Reply

  13. Hi Stepen

    we are facing below issue

    The base type ‘VSSP.PageLayouts.Templates.IntranetPageLayout’ is not allowed for this page. The type VSSP.PageLayouts.Templates.IntranetPageLayout, VSSP, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3499b5cce3f2192f could not be found or it is not registered as safe.

    « Microsoft.Office.Server.Search.Internal.UI.SearchResultsLayoutPage » n’est pas autorisé pour cette page. Le type Microsoft.Office.Server.Search.Internal.UI.SearchResultsLayoutPage, Microsoft.Office.Server.Search, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c

    Reply

  14. Hi – is there a solution for it? We have the same problem and no workaround helps.

    Reply

    1. Hi Steffen, a solution for what exactly?

      Reply

      1. Ah okay sry 🙂
        We have the same problem with custom solutions (masterpage, application pages) which are discribed above.

        “The base type ” is not allowed for this page. The type could not be found or it is not registered as safe.”

        AND

        :: Code blocks are not allowed in this file.
        System.Web.HttpException: Code blocks are not allowed in this file.
        at System.Web.UI.TemplateParser.ProcessError(String message)
        at System.Web.UI.TemplateParser.EnsureCodeAllowed()
        at System.Web.UI.TemplateParser.ProcessCodeBlock(Match match, CodeBlockType blockType, String text)
        at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding)
        at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding)

        We installed last week some security updates – then we got these errors.

        So I want to know or find out if the installation of CU October 20 will fix this issue.

        Thanks

        Reply

        1. Hi Steffen,

          this is caused by a design change introduced with a security fix.
          By default all masterpages, page layouts and pages which have inline code are blocked. If required each of these items need to be explicitely “allowed” to ensure that administrators are aware of any such code pieces.
          Details are here:
          https://blog.stefan-gossner.com/2020/09/25/trending-issue-after-installing-september-2020-cu-and-pu-custom-pages-and-controls-fail-to-render/

          Just to be clear: this is not something that will be “fixed” as this is the expected behavior if this security fix is installed.

          Cheers,
          Stefan

          Reply

  15. I am getting the same issue with Search Center and also in CA,

    IN CA:
    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=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c could not be found or it is not registered as safe.

    Search Center:
    An error occurred during the processing of /_catalogs/masterpage/searchmain.aspx. Code blocks are not allowed in this file.

    Anybody has good idea why is the reason behind this?

    Reply

    1. Hi Milinda,
      running the SharePoint configuration wizard should add the required entries to the web.config.
      Cheers,
      Stefan

      Reply

  16. Hello, Stefan.

    After installing the security updates recently, I can see the below error in our logs…..

    System.Web.HttpException (0x80004005): The Controls collection cannot be modified because the control contains code blocks (i.e. ).
    at System.Web.UI.ControlCollection.Add(Control child)
    at Collaboris.Readership.Web.WebControls.RibbonManager.get_ContainerControl()
    at Collaboris.Readership.Web.WebControls.RibbonManager.CreateChildControls()

    Thanks, Ca.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.