I'm having a lot of trouble opening documents from a network share in word using IE.
The documents are located in a network share which is mapped to a virtual directory. The documents are accessed by URLs that link to the virtual directory.
There is now a huge lag (sometimes up to a minute or two!) from when clicking on the link to the document opening in word. The 'loading disc' in IE just keeps spinning and nothing happens. Sometimes a pop up box appears with 'opening file - (address)' but it still takes ages.
I've tried setting in the registry to open the files directly in ie but to no avail.
Anyone have any ideas?
Steve
Related
Summary
Environment: Windows Server 2016, IIS 10, ASP.NET webforms site, Wildcard SSL/TLS Certificate, IIS URL Rewrite 2.1 (MS supported download)
Goal: a) Determine and resolve the root cause(s) of the issue, b) [preferred] Get the two failing features working without users having to change settings on their browser, c) get the two failing features working, period, without first-time-processing issues on ubiquitous browsers (Chrome, FF, Edge, IE, Safari, Opera).
Issue Summary: Two of the site features i.e. downloading files and displaying SSRS reports fail with a first-time-processing error or fail entirely, depending upon the browser, with the SSL certificate bound to the site. Subsequent attempts to execute these features within the same browser window succeed in most cases. Various browsers fail in different ways and some don't fail at all depending upon the browser in question. Please bear with me as I try to provide details below.
NOTE: Both features work fine without the SSL certificate in the mix.
I have scoured the Internet for a solution to no avail and would be very grateful for any assistance on this.
Details
I have a client with an ASP.NET Webforms site containing file download and SSRS report display features. Users must be logged in to access these features. Sadly, the original developers implemented a rudimentary, homegrown approach for authenticating users i.e. it's not a "formal" authentication framework but, rather just a simple comparison of the provided username/password pair to the values stored in the database ... no formal authentication tokens are set to my knowledge ... could this be part of the issue?
Both of the aforementioned features have been working flawlessly for years using all current, major browsers. My client recently purchased a wildcard SSL/TLS certificate which I installed on the production IIS instance and configured the appropriate site bindings. In case this matters, the site is also using URL Rewrite with a basic rule in the web.config to modify all HTTP protocol requests to the HTTPS protocol.
All aspects of the site work fine with the SSL certificate in place except file downloading and SSRS report displaying. Current versions of Chrome and Firefox [Windows], and Mac browsers (I don't have first-hand access to a Mac environment) are exhibiting errant behavior. IE 11 (go figure) appears to be the only browser with no issues whatsoever. I have not tested Edge as I don't have access to that browser version.
File Downloading
The site has a feature that allows logged in users to download files from the site.
Chrome
Chrome displays a first-time-processing error "Failed - Network error" shown in the download status bar at the bottom of the browser. Clicking the chevron in the error message and choosing the "Resume" option from the context menu completes the download but, any attempt to open (double-click) the zip archive from its actual folder location results in the following error message: "Windows cannot open the folder. The Compressed (zipped) Folder '{path}' is invalid." Analyzing the zip file in a hex editor reveals that it contains the web page source code and not the intended file download. Repeating the file download operation in the same browser window works fine (culminating in a successfully downloaded, valid zip archive of files) and all subsequent file download attempts also succeed with no further issues for the remainder of the life of that browser instance. If the user closes their browser (all Chrome instances must be closed) and then re-opens Chrome navigating to the site, the browser, again exhibits the first-time-processing error and then works fine from then on for the remainder of the life of that browser window.
NOTE: All instances of the Chrome browser must be closed to reproduce the issue a second time. If the user leaves even one Chrome instance open on their computer and then navigates to the site using a new browser window and retries the file download, there are no issues. Perhaps Chrome is caching some kind of an authentication token? I am intentionally shying away from using the term "session" as the behavior does not appear to be session related. Opening a new tab within Chrome (after experiencing the aforementioned first-time-processing behavior) and navigating to the site (which culminates in a new session) does not exhibit the issue.
Firefox
Firefox displays a "Secure Connection Failed" error message when trying to download files from the site. All subsequent attempts continue to fail. This differs from Chrome's first-time-processing only behavior. Modifying the Firefox advanced preference "network.http.spdy.enabled.http2" from true (the default) to false permanently resolves the issue.
IE 11
IE 11 does not fail at all. No browser settings were altered from the default installation of IE 11.
Mac Browsers
Mac users report that file download attempts appear to succeed but attempts to open the zip archive culminate in the Mac environment thinking that the zip archive is password protected. NOTE: There is no explicit assigning of a password to the zip archive in the code that processes the download request. No users in Windows environments report this behavior.
SSRS Report Display
The site has a feature that allows logged in users to display a PDF document created at runtime from SSRS. The PDF displays directly in the browser window (as opposed to immediately initiating a download operation).
Chrome
Chrome displays a similar first-time-processing error when the user attempts to display an SSRS report. The browser displays the following error message: "Error Failed to load PDF document." The error message has a "Reload" button which culminates in the report displaying successfully. All subsequent attempts to display reports in the same browser window succeed with no further issues. The first-time-processing behavior is, again, experienced when the user closes and re-opens Chrome to the site, and retries the report display.
NOTE: It is interesting that in Chrome with either feature (file downloading or SSRS report display), once the user has experienced the first-time-processing issue with either feature, then the other feature works fine with no issues for the life of that browser instance. Example: User opens new Chrome instance, navigates to site, and attempts to download files. The file download will fail the first time. Immediately attempting to display a report succeeds ... and vice versa.
Firefox
Firefox displays the same "Secure Connection Failed" error message as was the case with the file downloading feature. Modifying the same Firefox advanced preference "network.http.spdy.enabled.http2" from true (the default) to false permanently resolves the issue.
IE 11
IE 11 does not fail at all. No browser settings were altered from the default installation of IE 11.
I have an application that upload many files on the internet with TIdHTTP Indy component. Sometimes happen that many of those remain on the disk like "Temporary Internet Files" in the Internet Explorer directory and occupy several gigabyte.
Has anyone encountered this behavior?
Should I change the component?
[EDIT]: The cause of this problem wosn't TIdHTTP, but TDownloadURL! (that I use for download from another server)
i'm Opening Word File from my Application in HTTP Path
i.e. http:\Server\SiteName\TempFiles\filename.docx
Word File Showing message as "READ ONLY : This Document is Lock for Editing by another user"
because of this my macro didn't work
Protection = ActiveDocument.ProtectionType
If ActiveDocument.ProtectionType = wdAllowOnlyFormFields Then
ActiveDocument.Unprotect "password"
WordBasic.AcceptAllChangesInDoc
ActiveDocument.Protect Protection, False, "password"
Call updateCustomVariables
ActiveDocument.Saved = True
Exit Sub
End If
every thing is working fine
and still working fine on office (Word) 13,10 machines
this problem suddenly start from last 3- 4 days
i'm getting error as Command failed (Run time Error 4198) for office 16 for ActiveDocument.Unprotect "password" line
no office Updates
no windows update
please help..
Check trusted Location Setting of Word i.e. Allow documents from Network to be trusted
disable all Protected View options
I know this isn't an answer but I'm new here and can't comment yet ;)
Got the same problem with one of our customers. Issue appeared in the latest Office 365 monthly rollout (16.0.11901.20264) a few days ago. The semi-annual version (16.0.11328.20362) doesn't have the issue. Our files are served using a URL with parameters. With previous versions of office it displays Read Only in the title bar but allows the user to edit the content.
With the new monthly version there is a read-only message that displays under the ribbon with a link to Save As. User cannot change the document content unless he saves the file locally. Even worse Word makes requests without the parameters so our code abends. I changed the code locally to put the parameter information in the path and I can open the document. But it still says that it's locked and the user can't edit the content.
We open and manage documents them using a VSTO side panel so we don't need to save them using the Save button. The application has it's own Save button that retrieves the updated content, saves it using an AJAX call and closes Word. Nice change of behavior from MS ;)
On IE9 this works - but most of our staff aren't using the latest version.
We have a document library page that is pointing to various files in a networked folder.
This folder is accessible by everyone, and they do not have to use log on credentials.
When clicking on the link to the file, it pens a new web page, in which the file will be displayed.
Unfortunately, on IE's below 9, the web page remains blank, and no amount of tinkering (that I've tried) has given us access to is.
The link goes like this: file://intranet/documentation/Sedation%20protocol.doc
This is very urgent; and any assistance would be greatly appreciated.
EDIT:
We have moved this shared folder to a new server (From win server 2003 to win serer 2008), which is when th problems started.
Have found a 'solution' to this problemo:
Go to Internet Properties on Control Panel, then Security tab.
On the Local intranet tab,Click on Sites.
While there, untick `Automatically detect intranet network' and tick the remaining 3 boxes.
From there, Click on Trusted sites and untick Enable Protected Mode
That should sort it out.
EDIT: It seems as though some IE's still have a problem, so:
Open IIS7, and create a new virtual folder that links to the physical folder. After that, enable directory browsing on the Virtual Folder.
From there, its simply linking to the document in the Virtual Folder.
I am trying to open a windows shared folder on my network using the tag, however, I don't want a new browser windows to open or even reload my current one. I've tried all the target values and they all redirect to another page. Is it possible to open the folder without redirecting. Even with another tag. I am using asp.net.
thanks,
I had some success some years ago using an iframe with the source set to a network path. That produced an embedded Windows Explorer window. However, that was on IE; I don't know how another browser might behave.