I've seen couple of posts on this before (trusted sites etc.) and there is a KB (http://kb.pulsesecure.net/KB11282) I've tried to follow, but nothing seems to help. 6.5R4, Win7/IE8, Sharepoint 2007 combination is being used and clicking an Office document just opens a IVE sign in screen or gives another XML type of error.
Has anyone seen this and undestands why this migh happening? Someone said it's the Office DLLs OWASSUPP.DLL and NAME.DLL which are causing this, but I guess not in my case?
A bit more info for this. Just tested with Firefox and, while it's not "Sharepoint edit aware" like IE, all the files actually opened correctly from Sharepoint. Thus, I guess it's something with IE8 and Sharepoint add-ons or settings?
Can you verify that it only happens going through the IVE? I'm having IE8 on Win7 issues opening office documents in sharepoint just on the internal network. It pops up macro warnings and won't open the docs under certain circumstances. Excell seems to be more reliable than word.
yes, it only happens through IVE as we have about 700 users accessing those Sharepoint-files every day. No complaints about problems opening files.
I played around a bit more with IE settings and when I add IVE to the list of trusted sites, I can right click an Office document in a Sharepoint library and successfully open it for edit through IVE. However, direct click (read-only) will bring up the Sign-In screen.
It just crossed my mind that our internal PCs are Windows XP SP3 - perhaps there is indeed a difference between Win7 and XP? Have to try this at work.
tested it quickly with an XP desktop and works like a charm. Thus Windows 7 does something differently when opening files from Sharepoint or perhaps access rights on the file system or ...
Unfortunately, I don't have a solution for this yet.
We tried turning off UAC but that didn't help. We also get additional login prompts from the intranet during docment loads at time even though it is configured to pass credentials automatically.
I have a feeling one of us here will spend some quality time on a MS incident eventually. It just hasn't risen to that level of problem to devout the time to yet. But this is clearly an MS internal issue. They own the entire transaction.
We've worked around this issue by putting the domains of the Juniper and the sharepoint internal domain name in the registry as a multi-string-value with name AuthForwardServerList under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WebClient\Parameters
that is a nifty solution, thank you for sharing.