Saturday, April 22, 2006

Workaround for opening Office documents as read-only in SharePoint

In an earlier post, I ranted how opening Office documents (Word, Excel, PowerPoint) from SharePoint is a pain when you are using SharePoint from a different domain than your computer is logged in to. We finally found a workaround, which now seems obvious. Here's a review of the situation:

If your Windows machine logs into Active Directory domain "Homer," but the SharePoint site you access is on the domain "Lois" in a different location, you have to deal with login prompts instead of a streamlined integrated login. This is expected behavior.

In addition, Word, Excel, and PowerPoint documents opened from SharePoint need to authenticate the user as well, because the documents are actually opened from the web server, not the local browser cache. This is also intended functionality: the idea is that the user can edit the files and save them back to the server directly from Word, Excel, or PowerPoint. The user must type their username and password when each separate Office application is opened via the link for the document in Internet Explorer. Usually this is not a big deal.

However, opening documents from a SharePoint site in Internet Explorer is sometimes impossible when a third-party single-sign-on system is in place and the user doesn't actually have the Active Directory username and password handy. If the SSO doesn't know how to handle Office applications, it's impossible to open the files at all because they get stuck at the SSO login process. A workaround is to have users right-click the documents in SharePoint and "Save as," but chances are users would not get the message or forget.

So we finally came up with a workaround while we wait for a permanent solution via the SSO: Convert all Office documents to Adobe PDF. For documents that need to be available in the native Office format (.doc, .xls, .ppt, .vsd, etc.), compress them as .zip files. Use the .pdf and .zip files in the document libraries instead of native Office files.

This can work well for sites where SharePoint isn't being used for document collaboration, or where collaboration doesn't rely heavily on document editing. As far as I know, there's no other way around this problem other than converting the documents to non-Office formats or using a browser like Firefox, which doesn't try to open Office documents for editing from the web server.

We will figure out a permanent solution, but for the meantime the workaround will suffice.

37 comments:

Anonymous said...

Has anyone checked with the Microsoft Team to see if they have a solution for this?

Joelsef said...

Not directly. There wasn't anything I could find online.

I will try to hunt down the right person to ask.

Anonymous said...

Mmm. Only for Word, including version 11 (2003), http://support.microsoft.com/?kbid=324328 seems to solve the problem, which would indicate this is a client problem. I can not find similar keys for the other Office products.

However, the IIS over HTTPS will show only to accept Basic Authentication, since Windows Integrated won't get through the firewall, indicating it is a server problem.

These opposites puzzle me. Are they both true? Then why does the registry hack work for Word?

Who can shed a light here?

Joelsef said...

It's definitely a client problem, though it also depends on how the web browser provides the document. IE makes Word open the document from the server. Firefox makes Word open the document from the browser's cache, eliminating the login prompt (and any collaborative features).

Fixing registry keys is out of the question for us--this is an extranet deployment, so we don't have control over any users' desktops.

Our answer will need to lie in fixing the SSO to handle authentication when files are opened through Microsoft Office applications like Word.

Anonymous said...

so if the user is not able to open the .xls file from the SharePoint website, I will have to convert all of her files into .pdf or zip them up and only then she might have a chance to open it? How come I am not running into this problem with other users and they have no problems opening the file from SharePoint? Is there another workaround for this?

Joelsef said...

If your users are all part of the Active Directory domain in Windows, log in to the domain with their domain accounts, and access the site in Internet Explorer and Office 2003, you probably won't have any issues. This typically is the case on an intranet.

This problem I have described happens if your user is outside of your Active Directory network, typically if your users are not part of your domain use computers outside of your company's firewall. Alternately, this may occur if you use some sort of single-sign-on (SSO) system that overrides Integrated Authentication in IE and Office applicaitons.

You don't necessarily have to convert the files. This is just what we decided to do.

An alternative is to have users right-click and select "Save target as..." to save the file locally, then open it. That works to, but requires instructing the user and/or training.

Anonymous said...

I'm a new user to Sharepoint so I apologize if this question is elementary for you. What it happening when a Sharepoint user cannot open an a file in Sharepoint that was created in Excel format? He has the permissions to do so, but he gets an error message when trying to open the file. Thanks for your help

Joelsef said...

Hi Mary, What error message is your user getting? How is the user opening the file?

Anonymous said...

Saw this post and your workaround. Is there any other technical documentation explaining this problem?

Joelsef said...

I have not found anything, no.

Anonymous said...

Following up question on this blog....

Will WSS 3.0 / 2007 solve the issues of the login promt requirement when opening a documnet in IE?

Joelsef said...

Kevin, I am looking into this.

Anonymous said...

Anyone have any luck with this. We've just put up a WSS 3 site and want to use it for an extranet scenario and users don't like the extra logins.

Joelsef said...

I have not been able to try it myself, but I believe if you are using forms authentication or anything other than integrated authentication, Office applications cannot automatically authenticate. So I would assume you are stuck in needing each application to re-authenticate.

However, I have not tested this so if anyone has please let us know!

Joelsef said...

Here's some intel I got from Stefan and Spence: If using persistent cookies on an extranet (non-Integrated auth) for WSS 3.0, the documents open in Word, Excel, etc. as editable.

I haven't tried it myself but it's worth a shot!

Anonymous said...

Thanks joelsef

Anonymous said...

The workaround is just that ... a workaround! Now consider how you might work with this in an educational setting, where each computer may have up to a dozen users in a day. No chance to locally store the username and password.

This is a real show-stopper for education, who are looking for as few barriers to learning as possible. It doesn't take a genius to work out that this compeomises single sign-on, and adds to teacher workload.

Regardless of the technical reasons, it just shouldn't be so. How can this be a valued feature when it is so obstructive?

This is a serious issue that compromises the usefulness of the MOSS 2007 architecture for education!

There are quite a few portals for education that don't have this problem. This needs a real solution and a recognition from Microsoft that this is a 'naf' feature that needs to be sorted quickly ... or lose customers!

Anonymous said...

hi joel i was wondering when we open a document..from where the contents are displayed.. in case of checkout the documents gets cached in temporary internet files...but i do not see it in case of open..does it get displayed directly from server...i would really appreciate your great help..thnks in advance...

Joelsef said...

AFAIK, the document is always "opened" from the server but it should be cached locally somewhere in Temporary Internet Files. That said, I am not 100% sure how IE and Office handle it.

Anonymous said...

Hi,

it is unbelievable... To fix this problem you should use Mozilla Firefox as browser, as the Microsoft browser doesn't work as it should...
However, when using Firefox, other features seem to be disabled (I get messages all over the place as 'requires a Windows SharePoint Services-compatible application and Microsoft Internet Explorer 6.0 or greater.')
So, Firefox is great for opening Office documents without getting the annoying password prompt, but it seems to be locked out by Microsoft for some other functions, which is a pity.

Anyway, I hope Microsoft comes out with a fix for this annoying password prompts all over the place. This is really a show-stopper in demos, and it is really not appreciated by my end-users.

Moreover, I am getting this password prompt over and over again also in my Outlook 2007 client, as some SharePoint lists are added for synchronisation reasons. Is there also no solution to avoid this?

Matthew said...

You can completely get around this by publishing your Sharepoint from behind an ISA 2006 server when in Form Based Authentication.

When you publish using Form Based Auth and select "Private Machine" at login, you will be given a cookie that both IE and Office will read that will authenticate you to the AD/Sharepoint for each request.

You will no longer need to re-auth each time you go to open or save a document. Even if you navigate out of sharepoint and back you don't need to log in again. Only if you completely close your IE which will also clear the cookie do you need to sign in again.

Anonymous said...

What if you don't want to implement ISA? We only use this for intranet but I still can't find reasonal solution MOSS 2007...

Anonymous said...

In order to resolve that issue, you nedd to add the domain to the intranet zone in Internet explorer. You also need to activate the use the integrated logon feature in Internet Explorer. You can do both in the security tab.

Anonymous said...

I tried doing the intranet settings and pass through auth. It didn't work for our sharepoint sites.

Anonymous said...

Do u find another solution for this problem until now ?

Joelsef said...

Unfortunately, I have not.

Anonymous said...

Reinstall MDAC components
http://www.eggheadcafe.com/software/aspnet/29196156/files-opening-in-readonl.aspx

http://support.microsoft.com/kb/287402

BlackDeath said...

We have found that if it is an intranet zone and sharepoint does not necessarily have to have authentication then you can change your browser security settings for the local intranet zone for user authentication | logon to Anonymous logon. And then no more annoying dialogue box. Looking for a reg hack to push out to 2000 machines though.

BlackDeath said...

Found the solution at a microsft site for the reghack. Here it is:

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1]
"1A00"=dword:00030000

Anonymous said...

Just an FYI we have ISA 2006 and we have similar problems - the bottom line is client integration does not work with external partners!

right click save as. get a clue MS fix it!

Anthony said...

These are old posts. Is there a recent fix that MS has brought out?

Anonymous said...

Hey Anthony, have you read the MSFT SPPT blog regarding FBA patches in early May?

Unknown said...

I believe MS has an explanation take a look at this:

http://support.microsoft.com/kb/871155

Unknown said...

Unfortunately, the fix listed did not solve the problem of having to reauthenticate when opening an office document on a sharepoint server. If anyone knows of a fix, please list it here.

Anonymous said...

It's a problem related to Security Trust Center on each Office 2007 program.

Please try this:
Meke a Registry file with this data:


Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains]
@=""

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\mydomain.com]
"*"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Security\Trusted Locations]
"AllowNetworkLocations"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\PowerPoint\Security\Trusted Locations]
"AllowNetworkLocations"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Security\Trusted Locations]
"AllowNetworkLocations"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Access\Security\Trusted Locations]
"AllowNetworkLocations"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Security\Trusted Locations\Location12]
"AllowSubFolders"=dword:00000001
"Path"="http://test.mydomain.com/SiteDirectory/"
"Description"="SharePoint 2007 SiteDirectory"

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\PowerPoint\Security\Trusted Locations\Location12]
"AllowSubFolders"=dword:00000001
"Path"="http://test.mydomain.com/SiteDirectory/"
"Description"="SharePoint 2007 SiteDirectory"

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Security\Trusted Locations\Location12]
"AllowSubFolders"=dword:00000001
"Path"="http://test.mydomain.com/SiteDirectory/"
"Description"="SharePoint 2007 SiteDirectory"


(you must to replace test.mydomain.com by your website)
(you must create new locations belong to diferents web subfolder)

Anonymous said...

Has anyone tried this registry hack and does it work?

Unknown said...

To solve this problem , you can , force checkout of the document and then click the edit document. This will prompt you to check in the document when finished editing it.