SOLVED

Can't open office documents after installing January 2018 updates

Deleted
Not applicable

Installed KB4011599, KB4011579, KB4011653 and KB4056895 last night on our 2013 farm. Now this morning we can't open Office docs (xls, xlsx, docx, pptx) from document libraries. First we get prompted in IE that some documents can harm your computer... Clicking OK launches office app, but then get generic message that it can't open the document once the application opens. Have tried Edge, IE11 and Chrome with the same results. Firefox opens a copy, and Opera downloads a copy. Anyone else seeing this behavior? Browser file handling was, and still is, set to Permissive.

10 Replies
best response
Solution

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-2...

 

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.

Thank 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.

Yes, I copied the DLL over and did an IISRESET.

The 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.

Agree completely, psconfig is the preferred way to go.

I agree PSconfig is ideal, but not always plausible as it does take our farm down for at least 5 hours.   Or at least that is what it did last time. I am willing to try the copy of files, IISreset and then when we get time on the weekend, run the psconfig.   

 

 DLL files were compared from this location 

C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\CONFIG\BIN\

to each of the 4 web applications IIS directories

C:\Inetpub\wwwroot\wss\VirtualDirectories\Webapplication\_app_bin\

These two dlls were found only mismatched in a about half of all the locations

Microsoft.SharePoint.ApplicationPages.dll

STSSoap.DLL

 

We did run psconfig, yet we still exhibit the same annoying generic error "can't open document"

We cleared the SharePoint Cache for extra measure following the instructions provided here:

https://gallery.technet.microsoft.com/office/SharePoint-2010-2013-21f55320

Then we completed IISResets.

I believe we even rebooted the servers as well.

 

Is there some other sneaky location of cache or DLL files I should check?

 

 

 

There is no cache. I recommend using the Config Wizard and not psconfig due to what I see many people missing all of the appropriate switches.

I just want to come and say thankyou to the posted fix for this.. STSSoap.dll was a version mismatch..

 

The error that started this but hos absolutely no google-fu results is

Word error pops up and says

 

Cannot connect to network (Word 2016/O365)

and

Cannot open file (Word 2010)

 

thanks again for this tricky fix :)

 

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>"

1 best response

Accepted Solutions
best response
Solution

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-2...

 

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

 

View solution in original post