I've got a mysterious edge case with some Word 2016 users on Windows using my Word add-in.
I realize much more info might be required...but I also feel this is an issue that might have some proven ways to diagnose - or someone may know of a root cause.
My simple Word add-in pulls data from a MySQL db on my web server (via php) and stores it in localstorage. Works great in Word 2016 on multiple computers. A handful of users can't, essentially, download data and my solution throws errors for them.
I've even had 2 users on the same machine - one who can use my add-in, one who cannot (so each logging into different Windows accounts at the same institution. The user who was able to happily use my app is in IT and maybe had different settings).
My nose tells me there is an Internet Explorer security setting getting in the way...we've verified that localstorage is allowed.
When a user with the problem opens Internet Explorer directly, they're able to download data and use the app (part of it works outside of Word). As I understand it, Word 2016 Add-ins use Internet Explorer 11 to render html/js/css - and a setting changed in a user's IE11 settings area will cascade to Word 2016 add-ins.
Some of the weird details I've picked up:
Opening a new browser window from inside Word (clicking on a link in my add-in that opens a full web browser) prompts a "A website wants to open web content using this program on your computer" and points to Internet Explorer's Protected Mode. I've experimented with turning this on myself and can't recreate the issue.
The user isn't signed into O365. That doesn't seem to make a difference either.
Debugging via F12Chooser shows an [object error] with an error code of "-2147024891" and a "stack" message of "Error: Access is denied..." at the point where data would be pulled...I can't get much more out of the console.
The add-in is able to hit Firebase (I'm using Google's Firebase for authentication) and I get a response from their server...but not my ajax call to my php file.
Any thought or direction appreciated.
As described in the title, the app simply stops working after some time.
The application itself is a simple, one page form that pulls data from a webapi on another webserver by use of the Sharepoint WebProxy and displays that data using knockout.js. The environment and the Sharepoint Server (On-Premise, same domain as my Dev Machine) are configured correctly - supposedly - as described in
Configure an environment for apps for SharePoint (SharePoint 2013)
I can develop, debug in VS, deploy and open the App directly on the Sharepoint Site.
But after a while, when opening the app again without having changed or redeployed anything it stops at this point in the redirect process:
https://sharepointurl/_layouts/15/appredirect.aspx?instance_id=<some-guid>
and shows the "This page cannot be displayed" message. The Sharepoint Site still works.
There are no errors in the eventlog. Most of the time I can fix this by restarting the IIS service completely on which the Sharepoint Site resides. But sometimes even that doesnt work.
What could be the problem? Any Idea?
Update: The error is not consistent in that it may occur for user A but not for user B and even that can exchange after some time, so that the user B sees the error and user A can use the App.
Update: The error only occurs in IE 11 and doesn't happen when using Google Chrome.
Update: It seems as if Sharepoint 2013 Apps do not work with Internet Explorer 11, which I was using. As we had other issues with IE 11 and Reporting I downgraded my development machine to IE 10 and now it works.
Update: This had nothing to do with IE 11 either. The error eventually returned.
My first recommendation would be to have your client use the 32-bit version of Internet Explorer, even on a Windows 7 64-bit Operating System. Internet Explorer is the ideal browser for Active X and the preferred browser for SharePoint Online for Office 365.
Next I would recommend that your client configure Internet Explorer for SharePoint Online, to review the article detailing this process click here.
My last recommendation would be to have them install the latest updates and configure their computers for use with Office 365. The following links and instructions will detail that process.
So we couldn't open .pdf in the browser in our SP2010 site. I set the setting to permissive browser file handling in central admin. I then found out that there's a bug that if a site is created from a custom template the pdf files uploaded to that site will still prompt for either Save or Cancel. I ran a hotfix on the server
http://support.microsoft.com/kb/2459108
Consider the following scenario:
You set Browser File Handling to Permissive for a web application in the General settings page in SharePoint 2010 Central Administration.
You create a document library, and then upload an html document.
You open the html document in the browser.
Note You are not prompted to download the html document and it is rendered in the browser.
You select to include the content when you save the SharePoint site as a template.
You use the template to create a new SharePoint site in the same web application.
In this scenario, the Browser File Handling list setting for the document library in the new site is set to Strict. Additionally, when you open the html document, you are prompted to download the file.
Now when I click on a pdf with firefox I can open it directly but with internet explorer (8 and 9, default settings) I still can't do it, what's the solution here?
Edit: Maybe it always worked in firefox, anyway, when I create a new library it works as expected. How can I run this setting on all libraries?
There's a different, more subtle, but simpler root cause of this problem.
After much web searching and many hours with MSFT support, as hard as this may be to believe, it turns out that the root cause of my "SharePoint won't open PDF documents" problem was actually an Adobe extension/add-on. The symptom was an Adobe error msg "failed to open" after clicking the PDF list item in a document library. The culprit, an Adobe extension/add-on: "Adobe Acrobat SharePoint OpenDocuments Component".
I do not know how this got installed. What I do (finally) know is that this component actually does the exact opposite of what its name implies, i.e., it apparently prevents PDF documents from opening up when clicked in a SharePoint 2010 document library.
After various failed attempts to solve this problem (including changing "Browser File Handler" settings on the web app server from "Strict" to "Permissive" and other fixes suggested below and elsewhere on various blogs and web sites), nothing fixed the problem until we disabled this Adobe extension/add-on. Then, problem solved.
Note that you may not see this component in the "Tools > Manage Add-Ons" list until after attempting to open a PDF document from the library: apparently the add-on isn't activated (won't appear in that list) until an 'open' attempt is made. SO - if at first you don't see the component listed, try to open a PDF file and check the list again. If this component appears, disable it, and your problem is likely to go away.
Baffling, at best; or worse, actually nefarious on Adobe's part ...?
I'd still like to know how to get the PDF to open in a separate browser tab in IE vs. displacing the active tab. If anyone can help with that, please let me know! No custom coding solutions, PLEASE!
There is a better way to handle "Browser File Handle" issue. Take a look at my blog here: http://www.pdfsharepoint.com/sharepoint-2010-and-pdf-integration-series-part-1/
Solution #2 addresses Pdf extension without exposing entire Web Application to "Permissive" browsing. Setting "Browsing File Handle" to "permissive" opens too many vulnerabilities with other file extensions.
Thanks,
Dmitry
I have the same problem - originally installed Office Web apps, then turned that off, turned on the open in client application, then changed the setting on each doc library to open in browser .. Still have a problem with PDFs though.
If somebody includes a link to them in an announcement, then that person can open, other not. But only in IE - in FF there is no problme
Just change the Browser File Handling for the Web Application from the central admin as:
Central Administration > Application Management > Manage Web Applications
go to your Web Application example "http://sharepoint:80, just select it
from the top ribbon click "General Settings"
go down to "Browser File Handling" and change it to "Permissive"
If am not clear go to http://www.pdfsharepoint.com/sharepoint-2010-and-pdf-integration-series-part-1/
try this:
Make sure you're the site collection admin. Go into the site (not the central admin) and then go to site settings then go to site collection features. In there you will find the setting for " Open Documents in Client Applications by Default " it will probably be deactivated. Active it and you're good to go. users will then open attachments in their windows assigned applications, not the sharepoint web apps.
Also, try going into adobe reader and in the settings there is an option to open with the browser. check or uncheck it based on what you want it to do.
Encryption and SharePoint don't play well together
Right click My Documents or source folder
Select Properties > Advanced (button)
Uncheck "Encrypt contents to secure data"
This should solve many SharePoint problems you might have, including files not opening properly.
Appreciate this is an old post but still very relevant today. I spent a while trying to get this to work - just thought I'd share my findings.
This is specific to Adobe Acrobat. If you use a different PDF viewer, such as SumatraPDF the issue does not occur.
1. To prevent the 'Open, Save, Save As' dialog box in Internet Explorer:
This is specific to the versions of Acrobat. Set the following key/value:
Key: HKLM\SOFTWARE\Policies\Adobe\Acrobat Reader\*acrobat_version_number*\FeatureLockDown\cSharePoint
Value Name: bDisableSharePointFeatures
Value Type: REG_DWORD
Value: 0x1 (hex)
e.g.
For Acrobat X:
HKLM\SOFTWARE\Policies\Adobe\Acrobat Reader\11.0\FeatureLockDown\cSharePoint
2. To disable PDFs opening in the browser
This is specific to the versions of Acrobat. Set the following key/value:
Key: HKCU\Software\Adobe\Acrobat Reader\acrobat_version_number\Originals
Value Name: bBrowserIntegration
Value Type: REG_DWORD
Value: 0x0 (hex)
e.g.
For Acrobat X:
HKCU\Software\Adobe\Acrobat Reader\11.0\Originals
Thanks,
References:
Adobe Acrobat - Lockable Settings
Adobe Acrobat - General Application Settings
I had two clients with a save issue in SharePoint.
When they try to save they would get a a very generic error: "Document Could not be saved"
The only way they could get them into SharePoint was by:
Saving to local File System
Using the Upload option from the SharePoint menu
Configurations
Client 1: Vista and Office 2007
Client 2: XP and Office 2003
I was able to fix client 1 by having him Map a Network Drive to the Sharepoint Site.
After mapping the network drive, somehow the OS magically knew about the SharePoint documents folder and he was able to save.
I'm not having the same luck with Client 2.
It won't even let me map the network drive. I get an error (one that I did not take a screenshot of and don't remember the exact wording...sorry). but it was an error trying to map the network drive to the SharePoint site.
So, after some Googling, I had him go to Windows Update and download all the latest patches for his OS.
He claims he did, but is still getting the problem.
Before I do another WebEx and start taking stabs in the dark to try and fix him, I was wondering if any veteran SharePoint users have run into this same issue and what they did to fix.
Or, is there some OS setting I should be looking at that needs to be toggled/modified.
I can access his SharePoint site just fine from several PCs and make modifications and save as necessary.
Did you try running the Microsoft Office Diagnostics?
Start --> Microsoft Office --> Microsoft Office Tools --> Microsoft Office Diagnostics
Let that scan and repair any issues it finds and see if that helps. That tool has fixed similar issues for me many times.
We have several sites that use Forms Based authentication (FBA) within SharePoint. Many of them have been running for months without issues. Within the last week or two we have noticed the following behavior for users trying to access a Read Only Microsoft office document (currently only verified with the 2007 versions of Excel and Word).
The behavior we are seeing exhibited:
The Document starts to open
Within the Office application an IE Window opens with the FBA login screen. There is also a Hyperlink in the top left saying Skip to main content
Clicking cancel several times will open the document
If you identify the site as an IE Trusted site the login screen with the Office app, everything works as before (not an option for the majority of our sites)
Non offices files, like PDFs, do not exhibit this behavior
Non IE Browsers that we have tested (FireFox, Chrome) do not exhibit this behavior.
Is anyone else seeing this issue? I assume it was an update sent from Microsoft that has resulted in this issue, since we are seeing it on multiple sites where the code has not been updated.
Thanks
The issue we ran into is there was a policy file applied on our network that caused the UAC prompt to be disabled for Vista/Win 7. When this happens, protected mode gets turned off for the IE browsers, which caused the issues we were seeing.
If you want Office integration to work under forms authentication you should do the following:
Turn on client integration in Central Administration for the forms-auth-enabled application
Use persistent cookies for authentication in the forms-auth-enabled application
On the client computer, add the site to trusted sites in IE
If you still see a login screen embedded in Office documents that you open, try the following on the client computer (if Windows 7):
Go to Control Panel, User Accounts
Click Manage User Account Control Settings
Change slider to Never Notify
Click OK and reboot the computer