Microsoft Office (Word/Excel) Save/Open Window not showing Scrollbar for SharePoint sites RRS feed

  • Question

  • When trying to save to SharePoint using a Microsoft Office application such as Word or Excel, the Save As window does not show a scroll bar even though there are more items in the SharePoint site/document library than can be displayed in the window. Users have to click on one of the items and use arrow key on keyboard to move down the list.

    • Edited by PaulT.NB Wednesday, February 10, 2016 3:50 PM
    Wednesday, February 10, 2016 3:01 PM

All replies

  • Hi,

    Please check if the “Show vertical scroll bar” option is checked in Options > Advanced.

    If it doesn’t work, I suggest you post to Office forum. Since the issue is more related to Microsoft Office, you will get the most qualified pool of respondents there.


    Thanks for your understanding.

    Best Regards,

    Dean Wang

    TechNet Community Support
    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact

    Thursday, February 11, 2016 6:58 AM
  • Thanks Dean, the "Show vertical scroll bar" is enabled but still does not show scroll bar in Save As window. I have posted the question to the Office forum too :-)
    Thursday, February 11, 2016 1:24 PM
  • Did you found a solution for this? We're having the same problem.



    Thursday, February 18, 2016 4:24 PM
  • Hi, 

    we expirience the same problem here.

    Do you have sharepoint 2013 and installed CU Jan 2016? This was the moment when the scrollbar disappeared in our environment.

    No difference betwenn Office 2013 and Office 2016.

    Working with Sharepoint 2010 and Save/Open works fine.

    So it seems really to be a problem with Sharepoint and not with Office.

    Any one has a solution? I hope it will be fixed with the normal SharePoint Office Updates or CU Fabruary 2016. I try it in our testing environemnt in the moment. Results will come tommorow,

    Best regards 


    Edit 1:

    No change after appliying the Updates coming with windows udpates (CU is still downloading)

    MS16-015: Description of the security update for SharePoint Foundation 2013: February 9, 2016

    MS16-015: Description of the security update for Word Automation Services on SharePoint Server 2013: February 9, 2016

    MS16-015: Description of the security update for Excel Services on SharePoint Server 2013: February 9, 2016

    MS16-015: Description of the security update for SharePoint Server 2013: February 9, 2016

    Edit 2:

    Installed CU Feb 2016

    February 9, 2016, cumulative update for SharePoint Server 2013 (KB3114726)

    Still the same issue on Save/Open Dialog in Office

    Friday, February 19, 2016 2:35 PM
  • Have you found a solution for this yet? I am having the same exact issue with Word, Excel, and PDFs.

    Thanks in advance!

    • Edited by Quigley0908 Monday, February 22, 2016 2:57 AM
    Monday, February 22, 2016 2:57 AM
  • Nope. We will raise a call at Microsoft
    Tuesday, February 23, 2016 8:37 AM
  • No solutions yet.

    This most likely happened after we installed update KB3114503 or KB3114508. We had to install KB3114508 to fix the list issue in KB3114503.

    Georg, let us know if you can find a solution. Thanks.

    Tuesday, February 23, 2016 6:11 PM
  • I had the same issue and would only lose scroll bars when trying to save to a Sharepoint site.  If I picked a location like my documents on my computer then I had scroll bars.  My problem ended up being the way I had my Sharepoint drive mapped to my computer.  I had mapped it as a network location but ended up remapping to a drive letter and fixed the problem.  I now have scroll bars when I click on the drive letter to save to the Sharepoint site.  I would suggest at the least remapping your Sharepoint to your computer and see if it fixes the issue.
    Friday, February 26, 2016 8:17 PM
  • This does work, but unfortunately has security risks. That is why I believe Microsoft allowed the creation of shortcuts to these SP libraries. I used to have my SP Sites set up like this, but switched it due to security risks. I have actually had the security risk happen to me before. If you get a virus like cryptolock on any of your computers that have a SP network drive, cryptolock automatically looks for networked drives and starts encrypting them (i.e. your SharePoint Network Drive) and starts encrypting SharePoint data...But, if you have it as a shortcut or Quick Access/Favorite, cryptolock doesn't do anything to these files.

    Burn me once, shame on me, burn me twice because MS messed up something, so I had to revert back to the non-secure way of connecting to SP libraries...not even going to happen lol.

    It's obvious that the mapped drives to SP sites are totally different, or Windows in particular treats them differently. If you go into a Quick Access/Favorited SP Site, you can clearly see the format of the files and folder fonts is changed and the window displays that you are on a SP Site. Something is different...not sure what because they both appear to use WebDAV...?

    Friday, February 26, 2016 10:08 PM
  • Was a solution discovered for this?
    Tuesday, March 1, 2016 12:16 PM
  • I haven't found anything nor heard of anything yet.
    Tuesday, March 1, 2016 4:25 PM
  • No news from here
    Tuesday, March 1, 2016 4:48 PM
  • Definitely happened after the SharePoint windows update. I was able to replicate the issue on a development server after SharePoint updates were applied.

    If you create a network location or favourite using "\" rather than the normal "/" you can work around the problem.

    eg: Save as \\SharePoint\YourSite instead of http:// SharePoint/YourSite. 

    The issue in my company is that most users have been trained to "Open with Explorer" and save as a favourite. I think its too hard to get most users to change all the "/" to "\" and resave all the network locations and favourites.

    Wednesday, March 16, 2016 1:58 AM
  • Using WebDAV is no alernative for us :(

    I just installed CU March 2016 in our test Environment. (KB3114827).

    No changes on the behaviour. Due to some projects I was not able to open a case at Microsoft yet

    Wednesday, March 16, 2016 12:01 PM
  • I opened a case on this too after installing the Feb 2016 CU. The support engineer I'm working with said he is already working the same issue with another customer.  Here are my notes:

    If we map the SP library as a network drive on the client machine, the scrollbar is present.

    Also, if we try to save the file to SharePoint while working from a Windows Server machine as the client, the scrollbar is present.

    This does not seem to be limited to just Office applications. Even if you try to save a non-Office file like: notepad to a SP library, the issue persists.

    To help ensure that the problem is not client side, I established a VPN connection with my personal laptop to my company’s intranet and duplicated the problem. The scroll bar is there when I try to save a word document to my sharepoint-online library but it disappears when I point at one of our production on-prem sp2013 farms.
    Before we installed the Feb 2016 CU, all our Office 2013 clients (Winword, Excel) on our workstations showed a scroll bar when trying to save a document to a sharepoint library. After we installed the Feb 2016, the scroll bar disappeared. Fortunately users can still navigate down the list using the keyboard arrow keys. We jumped from the May 2015 CU to the Feb 2016 CU. The same problem was observed in our PROD farm, our QA farm, and our DEV farm.
    As a simple test, I created a brand new sp2013 stand-alone farm, kept things simple, installed SP1, confirmed the scroll bar would appear, installed FEB CU, confirmed the scroll bar disappeared.
    If I try to save a word document from my desktop winword application to any of our sp2013 servers, the scrollbar disappears. If I then try to save the same document in the same client to one of our SP2010 farms, the scroll bar reappears. And if I try to save the document to a sharepoint-online-o365 site, the scroll bar returns.
    Fiddler traces made while saving to the sp2010 farm show a little extra _vti activity than the save to sp2013 does. But both traces seem to focus on owssvr.dll and look basically identical to me. I'm not so sure fiddler is going to help here.
    I am not seeing any error messages of any kind.
    I confirmed that bypassing the F5-BigIP load-balancer and going straight to one of the WFEs does not influence the symptom.

    Wednesday, March 23, 2016 7:51 PM
  • The case I opened with Microsoft is making progress, but it is very slow progress. Several cases have been opened on this issue and I have been assurred that the SharePoint Product Group is investigating it. No private fix has been realeased yet, as of April 13th, 2016. No guarantees have been made about a hotfix being made on this either. I suspect a fix might become available soon and then rolled up into the May or June 2016 Cumulative Update but that is unfounded speculation on my part which I can offer no substantiation for.  

    For now the workaround I have been recommending to my endusers is to simply use their down-arrow on their keyboards. If the users can handle that, that's probably the best option for now.

    However, two additional workarounds have been identified as possible short-term options to consider cautiously. Note that neither are good workarounds for managing in the long-term. Also note that the first workaround might be preferable to the second workaround.

    The standard disclaimers apply: no one is actually recommending that you use these workarounds. So use at your own risk. There are no guarantees about what affects it might have on the browsing experience of your clients. If it breaks something else, don't blame anyone but yourself. If you're not comfortable with making and testing these changes, don't do it. And of course the standard caveats apply: test it in a test environment first, be sure to make backup copies of the files before modifying them, log the changes in your farm documentation to keep track of them, keep in mind that the files may or may not get overwritten by future sharepoint updates, set a calendar appointment reminder to review whether the change should be backed out, etc. 

    ======Workaround #1========

    On each WFE SharePoint Server, locate the following two files:

    C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\FEATURES\DocumentLibrary\DocLib\FileDlg.htm

    C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\1033\filedlg.htm

    Open them for edit and remove the following line:

            <meta http-equiv="X-UA-Compatible" content="IE=10"/>

    Save the file. You may need to restart the Web Application App Pool for your SharePoint Web Apps, or perform an IISRESET.

    "These lines were added to two template files that are used to build out FileDlg.htm on our backend. There are many more copies of the FileDlg.htm on your server(s) but those should fix the majority of document libraries. If you find other libraries for other types of site collections, you may need to make those changes across all copies of filedlg.htm found in the \TEMPLATE subfolders."

    =========Second Workaround=========

    Open C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\1033\STYLES\COREV4.CSS in notepad. Add the following lines to it and save.





    • Edited by C. T. Haun Wednesday, April 13, 2016 2:44 PM better
    • Proposed as answer by JohnBontjer Thursday, April 21, 2016 10:07 PM
    Wednesday, April 13, 2016 2:41 PM
  • Awesome follow up Christopher! I'll be anxiously awaiting any hotfix news on this. Thanks again! I certainly appreciate it!
    Wednesday, April 13, 2016 3:02 PM
  • Just wanted to say I'm having the same issue after applying the December 2015 CUs to multiple farms. I used the first workaround on a test farm and it successfully brings back the vertical scroll bars. I'll probably open a case on this as well because I'd rather not have to make those edits in prod.
    Thursday, April 21, 2016 8:00 PM
  • I have been told that the fix will *probably* get rolled into the June 2016 CU. That is what they're aiming for. But it will take time to test it and be sure that it's good. So there is no guarantee of it making it into the June CU.

    So far no private hotfixes have been offered. So I'm not sure there is any point in opening a case.

    Thursday, April 21, 2016 8:02 PM
  • This is correct, we have opened a case with Microsoft. The support engineer came up with the same Workaround #1.

    If you have installed multiple languages, repeat these steps for other LCID folders.

    And yes Microsoft will try to ship a more permanent solution into the June 2016 CU.

    So if you have this same problem, use Workaround #1. as proposed by Christopher.

    • Edited by JohnBontjer Thursday, April 21, 2016 10:11 PM
    Thursday, April 21, 2016 10:10 PM
  • How come it works on Office 365 SharePoint Online?

    Did MS fix it there using the above "workaround 1"?

    Or some other fix that they haven't released to on-prem, and might not release to on-prem?

    This is a deeply uncool way of forcing on-prem customers to go Office 365.

    Wednesday, April 27, 2016 3:01 PM
  • My guess is that SharePoint Online is probably using SharePoint 2016 rather than 2013 like us. Significantly different code bases mean this bug might affect only 2013 and not 2016. Just guessing.
    Wednesday, April 27, 2016 3:05 PM
  • It appears the problem was introduced, albeit in a disguised form, prior to the Dec 2015 CU, but I haven't found another thread that mentions it yet.

    In the Nov 2015 CU (and possibly earlier) the scrollbar is not present when the Open, Save, or Save As dialog is positioned on a folder in a library.  It is present in this case when the dialog is positioned on a site.  So it is partially broken, whereas the Dec 2015 CU and later is totally broken.

    Just in case anyone is reading this and deciding, like we did, to go with the "last known safe" CU, per the above, of Nov 2015, it's also dysfunctional - only not quite so dysfunctional as the Dec 2015 CU and later.

    Rather sums up the MS patching process experience of late:  More dysfunctional the closer to today's date you get; in other words, the exact opposite of what one would expect from a patching process.

    Tuesday, May 3, 2016 11:27 AM
  • When I use workaround #1, I then get a script error saying:

    An error has occurred in the script on this page.



    Error: Object doesn't support property or method 'attachEvent'

    Code: 0


    Do you want to continue running scripts on this page. Whether I click yes or no makes no difference.

    Friday, May 6, 2016 2:40 AM
  • Has anyone tried the May or June updates to see if it fixes these. We have the same issue.

    Tuesday, June 21, 2016 12:35 PM
  • Hey Guys,

    It's finally here!! The June 2016 CU that is supposed to fix the issue we were all discussing in this forum. Has anyone applied it, to see if it fixes the issue?

    I should be applying it this weekend. So I will let you know my results once it's applied.


    Tuesday, June 21, 2016 6:06 PM
  • Well, that was extremely disappointing. I applied the June updates, that specifically say they will fix the scrollbar issue, and it did not fix the scrollbar issue....

    Please tell me I am not the only one in this boat...

    Wednesday, June 22, 2016 3:20 AM
  • We have not tried the June CU yet since the workaround has been working so well for us. I still have the case open with MSFT and see what they know.
    Wednesday, June 22, 2016 2:18 PM
  • Still waiting on MSFT support for an answer.
    Friday, June 24, 2016 8:22 PM
  • Awesome, thanks for checking Chris, I for one really appreciate it!
    Friday, June 24, 2016 8:30 PM
  • The June 2016 CU definitely *should* fix it. But unfortunately I can offer no insights so far on why it didn't work for you. Sorry.

    Also, in the file replace operations the installer will compare the hash of the existing filedlg.htm files to ensure that it matches what it expects for the affected file. Otherwise it won’t replace the file. If the file has been modified it won’t be replaced. To remedy that the modified files should be restored from a backup prior to the update being applied. Alternatively, after installing the fix on all servers, if there are APP servers which never had the filedlg.htm files modified in the workaround, you can copy the new (June 2016 CU) files from the APP server to the WFEs.

    That's all I've got for now.

    Wednesday, June 29, 2016 3:25 PM
  • Can anyone confirm that the June 2016 CU fixes this issue? I can't reproduce it and a client is waiting for it.

    Hope anyone can help.

    With Kind Regards,

    Robin Kruithof

    Technical Consultant EPM

    Friday, July 1, 2016 1:57 PM
  • I can confirm with CU July 2016 the Problem is fixed. We installed the CU in our test environment and the problem vanished.

    Scrollbars are now available in Office products when selecting SharePoint sites

    Tuesday, August 2, 2016 11:13 AM
  • Nice! Thanks for the heads up! I will give it a try and post back my results. Did you try to install the June CU and had no success also?

    Thanks again!


    Tuesday, August 2, 2016 2:07 PM
  • Sorry, I just gave July 2016 CU a try. We stepped over June 2016 CU.

    July 2016 CU will be deployed to our production Environment in two weeks. Hope no other issues arise :)

    Tuesday, August 2, 2016 2:17 PM
  • Hey Christopher!

    So I checked my filedlg.htm and it doesn't look like the modified date is the same as the date as when I applied the update...

    I tried applying the July CU with no success either...

    I do not have a backup I can go to without missing tons of data.

    Are there any other solutions for me to try?

    Thanks again for your help!

    Sunday, August 14, 2016 4:05 AM
  • You might consider opening a support case with Microsoft's SharePoint Admin team, make it very clear that there is a bug involved (I don't have the bug number myself but you can reference my case 116032213860759 so they can know for sure which bug it is), and get their recommendations. They shouldn't charge you for a true bug case.

    The engineer working my case sent me a zip file containing "a package of all filedlg.htm files from a POST June 2016 CU install. You can extract the contents of the attached file to your 15/TEMPLATE folder and let it overwrite. This will bring all versions of that file in line for future updates." Maybe the engineer could do something similar for you. I'm not sure. I'd offer the zip file they gave me but (1) I don't want any additional email spam by putting my email address out here, (2) people shouldn't trust strangers on technet forums anyway, and (3) the zip I have is post June 2016 CU but pre-July CU.

    Good luck!

    Monday, August 15, 2016 4:51 PM
  • Awesome! You're the man Chris! I know you didn't have to give me any of that information. And I greatly appreciate it. I do agree with your 1,2, and 3 completely. lol.

    Thanks again for your help!!

    - Justin

    Monday, August 15, 2016 6:47 PM