Forum Discussion
Can't open office documents after installing January 2018 updates
- Jan 16, 2018
Hi Dean, we got hit by this problem today - in our case we received some unexpected hotfixes on our Sp2013 servers which caused the problem. No one could edit MS Office documents from on-prem SharePoint -- they could download and open the files locally but couldn't open/edit/upload MS Office files directly.
The error message was: Sorry, we couldn't open 'http://server/sites/site/lib/file.docx'
We opened a support ticket and our support engineer pointed us to this article:
https://blogs.msdn.microsoft.com/rodneyviana/2017/12/05/after-updating-sharepoint-2013-to-november-2017-cu-or-later-you-may-not-be-able-to-open-documents-with-office/
Long story short we had two different versions of STSSOAP.DLL on our WFEs (15.0.4981.1000 vs 15.0.4911.1000). Run PSConfigWizard to update your server's binaries - normally we should be able to run updated binaries for a short period before running PSConfigWizard but this hotfix seems to behave differently. Also, some of our users were not impacted - this seems to be due to the corresponding patch levels on the workstations (and this made troubleshooting a little more difficult.)
HTH
Hi Dean, we got hit by this problem today - in our case we received some unexpected hotfixes on our Sp2013 servers which caused the problem. No one could edit MS Office documents from on-prem SharePoint -- they could download and open the files locally but couldn't open/edit/upload MS Office files directly.
The error message was: Sorry, we couldn't open 'http://server/sites/site/lib/file.docx'
We opened a support ticket and our support engineer pointed us to this article:
https://blogs.msdn.microsoft.com/rodneyviana/2017/12/05/after-updating-sharepoint-2013-to-november-2017-cu-or-later-you-may-not-be-able-to-open-documents-with-office/
Long story short we had two different versions of STSSOAP.DLL on our WFEs (15.0.4981.1000 vs 15.0.4911.1000). Run PSConfigWizard to update your server's binaries - normally we should be able to run updated binaries for a short period before running PSConfigWizard but this hotfix seems to behave differently. Also, some of our users were not impacted - this seems to be due to the corresponding patch levels on the workstations (and this made troubleshooting a little more difficult.)
HTH
That was indeed the problem. The STSSOAP.DLL file version was different in C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\CONFIG\BIN\ than it was in some of the C:\inetpub\wwwroot\wss\VirtualDirectories\web.app.com\_app_bin\ directories on our front ends. Also noticed that Microsoft.SharePoint.ApplicationPages.dll was affected as well. Updating those two DLLs in all the _app_bin directories on our front ends cleared the problem up for us.
- ArthurEzenwanneNov 01, 2018Copper Contributor
Hi,
Thanks for this. In my situation, I checked the STSSOAP.DLL files on all webapplications and in the 15 hive config bin. They are all of the same version 15.0.4525.1000. (Windows explorer also shows that both were modified same date and same time and are of the same file size)
The only difference is: while STSSOAP.DLL in the webapplication shows a property date created of 26/03/2015; the STSSOAP.DLL in the 15 hive config bin shows a property date created of 23/01/2014.
Would that have any meaning? SInce we get the "Sorry we couldn't open <URL_OF_RESOURCE>"
- ChillyApr 24, 2018Copper ContributorThank you for sharing this, I believe our system is experiencing the same effects and I did confirm the STSSOAP.DLL is mismatch for 2 out of 4 of our servers. I didn't check any other files, but now I will.
Just a quick question on how you updated the DLLs.
When you updated the DLLs in the _app_bin directory, did you just copy the files over and complete an IISreset?
We are currently in a similar situation and It would be nice to address this without having to take our farm down hours.- DeletedApr 24, 2018
Yes, I copied the DLL over and did an IISRESET.
- Apr 24, 2018The proper way to do this is via psconfig [...] -cmd applicationcontent [...] or preferably via the Config Wizard so you don't unintentionally miss any switches from psconfig.
Psconfig/Config Wizard should always be run immediately post-patch. The methods in binaries may not match, and this isn't an unusual occurrence.