Trending Issue: left navigation missing after applying May 2022 CU for SharePoint Server 2019 – Updated

[Update: this issue is fixed with August 2022 CU September 2022 CU or later]

In the last couple of weeks we received several support cases (and comments on my blog) that after applying May 2022 CU the left navigation menu on modern pages in SharePoint Server 2019 is not showing up.
The problem is caused by an old javascript file being cached in the browser.

For most JavaScript files this problem is avoided by adding a version specific query string parameter to the javascript file, e.g. /_layouts/15/next/spclient/en-us/sp-dataproviders.js?uniqueId=3kOKi

After installing an update the query string parameter will be different guaranteeing that there will not be a cached instance of the javascript file with the new parameter in the browser cache. This forces the browser to pull the latest version down from the server.

Unfortunately there are a couple of JavaScript files where this parameter is not included in the request Url. The Urls to these files will not change with a new update causing the problem that a mix of new and old JavaScript files are executed in the browser. Clearing the browser cache or using CTRL-F5 resolves the issue but it is required to be done by all users in all browsers.

The issue is currently being investigated by the product group but there is also a very easy workaround to prevent the issue from happening: enabling the side-by-side functionality.

The side-by-side functionality allows to enforce that a specific version of a javascript file is being served by the SharePoint server. The original idea is to guarantee consistency between different SharePoint servers during zero-downtime patching but the same feature can also be used to ensure that the latest version of the javascript files are loaded by the browser in this specific situation.

If the side-by-side functionality has not been enabled before, the following steps are required after installing May 2022 CU:

1) Verify that the version specific side-by-side directory has been created in the layouts directory

If this directory is missing you can create it using this command:

 

2) Set the side-by-side token to the version number reflected by the directory

 

3) Enable the side-by-side functionality

An IISRESET might be required to ensure that the new settings is active.

Afterwards all javascript files will be requested with an URL which includes the specific side-by-side token.

More details in the my previous articles about Patching using the side-by-side functionality.

29 Comments


  1. Good morning, Stefan. I have followed the steps you provided but still occasionally we are getting “Sorry we couldn’t open [URL for .XLSX or .DOCX] and in Excel it throws a second Microsoft Excel Cannot Access The file [URL for .XLSX] there are several possible reasons. It is very hit or miss but it seems the documents for the users open successfully 30% of the time. I’m not sure if anyone else has experienced this or not through my searching online. Thanks as always for your help.

    Reply

    1. Hi Daniel,
      I haven’t heard about such an issue. The issue above is persistent till the browser cache is flushed. It is not an intermittend issue.
      I would recommend to open a support ticket for the issue you are facing to get it analyzed in more detail.
      Cheers,
      Stefan

      Reply

  2. Hey Stefan, so if I want to set $webapp.WebService.EnabledSideBySide value back to default (false), will the SideBySideToken value be automatically ignored? If not, do I need to specifically nullify the value ($webapp.WebService.SideBySideToken = “$null”) to target the latest token value available?

    Reply

    1. Hi Sam, yes it will be ignored. The value is only used if side-by-side is enabled.

      Reply

  3. Hello Stefan, I followed your tips but my left menu does not appear. Any other suggestions?

    Reply

    1. Hi Alessandro,
      if it is the same issue just flushing the browser cache on a client machine would resolve it.
      If you applied the side-by-side token workaround, please double check (e.g. using browser dev tools) that the JavaScript files now include the version number in the Url.
      Cheers,
      Stefan

      Reply

      1. I checked and javascripts point to the correct version number (16.0.10386.20011 in my case). Flushing cache does not resolve the issue as well.

        Reply

          1. Hi Stefan,
            I confirm that the issue has been fixed after language dependent patch installation.

            Thank you!
            Alessandro


  4. I am experiencing this issue after our latest patches, however none of your fixes have resolved it. The only pages that work correctly for me our classic pages. All Modern pages have no navigation on the left menu, I cannot even get Change the look or Site information from the settings cog to work. Also there is no search box on my modern pages. What should we do??? My only workaround is to recreate pages as classic pages.

    Reply

    1. Hi Aaron,
      did you install both patches? Language independent and language dependent?
      If only the language independet one was installed, then the workaround will not work. You have to ensure that both fixes are installed.
      Cheers,
      Stefan

      Reply

      1. Yes both patches have been installed KB5002207 and KB5002108 both display in Central Administration and when I verify installed updates when I go to Programs and Features on my Application Server. We ran the Configuration Wizard etc.

        Reply

        1. Hi Aaron, if clearing the browser cache does not solve the issue, it is not the same issue. The problem I was referring here is caused by a mix of versions for JavaScript files. After the cache is flushed it is guaranteed that a consistent version of JavaScript files is loaded into the browser.

          That said: i would suggest to open a support case to get the issue you are running into analyzed.

          Cheers,
          Stefan

          Reply

      2. One thin I do notice in the TEMPLATE>LAYOUTS directory, I see 16.0.10386.20011 NOT 16.0.10386.20015 as in your image above, is that an issue?

        Reply

        1. Yes – it indicates that the side-by-side directory for the language dependent fix was not created. Please run “Copy-SPSideBySideFiles” cmd let in the management shell. If that does not create the directory, then the language dependent fix is not correctly installed or PSConfig was not run after it was installed.

          Reply

          1. Hi – Just noticed that you mentioned the fixes KB5002207 and KB5002108. The correct language dependent fix for May CU is KB5002206. KB5002108 is the language dependent fix January CU. Please ensure to have language dependent and language independent fixes in sync.


  5. Important. Windows automatically installs the Security Update for Microsoft SharePoint Server 2019 Core (KB5002207) but does not install related language-specific files. As a result, the update breaks the left navigation in chrome and likely other modern browsers (it seems like navigation keeps working with the old IE11 browser). Install missing needed language-specific updates to fix the problem.

    Be aware that the language-specific update seems to actually cause IE11 to stop rendering the left menu. So this is not the perfect fix.

    **Always test fixes before the actual production environment. Do not allow Windows to install SharePoint-related patches without admin consent. **

    Reply

    1. Hi Pasi,

      this will happen on single server installations if you decided in windows update to install security fixes for other Microsoft Products.
      As SharePoint fixes should be evaluated and installed carefully it requires extra care if this settings is enabled.

      Cheers,
      Stefan

      Reply

  6. Hi Stefan

    1) On a multi server farm, you run the PoweShell once as it affects the whole farm, clear. What about IIS reset though, you have to perform it to all servers (wfe/app)?
    2) If we want to revert after the patching to initial state, when is it safe to run the “$webapp.Webservice.EnableSideBySide = $false;” ? After all users visit SharePoint and are redirected to correct JS or after lets say some minutes/hours/days pass and caches are flushed on server?

    Thanks
    A.

    Reply

    1. Hi A,
      first of all: there is no technical need to disable side by side. You can keep it enabled forever.
      It is not possible to say when it is save to revert. That depends fully on when the cache in the browsers has been invalidated.
      That can take days or even weeks (e.g. if a person is on vacation).
      Cheers,
      Stefan

      Reply

  7. Hi Stefan,

    I am experiencing the same issue but with the June core update on SharePoint Server 2019. I have installed the latest core and language pack updates and the left navigation is missing as well as the commandbar on the modern site pages.

    I have tried so many things (including your option above) and everything seems to come back to 3 javascript files that are giving errors 🙁

    sp-pages-assembly.js
    /_layouts/”hive version 15 or 16″/”SP version folder”/next/spclient/en-us/sp-pages-assembly.js

    5.sp-pages-navigation.js
    /_layouts/”hive version 15 or 16″/”SP version folder”/next/spclient/5.sp-pages-navigation.js

    13.sp-command-bar.js
    /_layouts/”hive version 15 or 16″/”SP version folder”/next/spclient/13.sp-command-bar.js

    Any advice or suggestions would be greatly appreciated. I have version 16.0.10387.20008 installed

    Reply

    1. Hi Clive,
      does CTRL-F5 resolve the issue on a single client machine?
      If yes, applying the side-by-side workaround should help.

      If not, double check that KB5002211 and KB5002212 (both are required) are installed on all servers in the farm.

      Cheers,
      Stefan

      Reply

      1. Hi Stefan, Ctrl + F5 did not work for me. I did however clear the SharePoint Server Cache and that worked. Then all clients were working 100%

        These steps should be executed for each server in your SharePoint Farm:

        Stop the SharePoint Timer service on each of the servers within the SharePoint farm.
        Click Start, go to Administrative Tools, and then click Services.
        Right-click SharePoint Timer Service, and then click Stop.

        Note: By default, these folders may be hidden. To view hidden folders, in File Explorer, click View and check the box for Hidden Items

        Navigate to the following folder: %SystemDrive%\ProgramData\Microsoft\SharePoint\Config
        Note: The %SystemDrive% variable relates to the drive on which Windows is installed; by default, this is the C: drive. You may find multiple folders with similarly formatted names containing files similar to below; these steps should be executed for each of these folders.

        Locate the folder that has a GUID as a name, such as a326e515-0047-4328-832c-02927b84d98c (my one was 00000000-0000- etc..)

        Open the relevant folder and 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

        Once these steps are done for each GUID folder on a server, start the SharePoint Timer Service again.
        Click Start, point to Administrative Tools, and then click Services.
        Right-click SharePoint Timer Service, and then click Start.

        The SharePoint Timer Service will begin populating this folder and modifying the number in the Cache.ini file.

        Reply

        1. Hi Clive,
          thanks for sharing. I have not seen this flavor of the problem.
          Would be interesting to understand which object was inconsistent in your scenario.
          Cheers,
          Stefan

          Reply

  8. Hello Stefan,
    we have the same problem. But only in one Webapplication, the other one seems to work well (no tickets with the failure)

    Reply

  9. Unfortunately, nothing has worked in our standalone server. July 2022 CU install, no change, Cache cleared. no change, ran IISReset, no change, running SidebySide scripts, no change, Ctrl-F5, no change!!

    Anyone have any additional troubleshooting steps I can try!

    Reply

    1. Hi Dave,
      if CTRL-F5 does not help the underlying issue for your problem it different from the one described in this blog post.
      I would recommend to open a support case with Microsoft to get this analyzed in more detail.
      Cheers,
      Stefan

      Reply

  10. After updates KB5002212 (SharePoint Server) and KB5002108 (Language Pack) I stared having the same problem. IMy far have 2 Front End: only one is affected by the problem (401 on _layouts/15/SPAndroidAppManifest.aspx). Does anyone found a solution?

    Reply

    1. Hi Fabbjo,
      it looks as if you installed January 2022 CU for the language related fixes (5002108) and June 2022 CU for the language independent parts (5002212)
      You need to apply June fixes for the language dependent fixes to ensure that both are consistent.

      KB 5002211 – June 2022 Update for SharePoint Server 2019 (language dependent)

      Cheers,
      Stefan

      Reply

Leave a Reply

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