3

I have a Window Server 2003 domain running Sharepoint MOSS 2007 SP1 v12.0.0.6219. My problem is that all users on the domain that lack local-admin rights to their currently used machine open all documents in Read-Only mode.

This is obviously a problem for me as I need users to be able to change documents through the check-out process. I am unwilling to blanket-grant all users local-admin rights for obvious security reasons.

Domain admins, power users, and users granted local-admin rigths to the box can accomplish this task without any abnormal behavior.

I have Googled this problem extensively, and can find no working solutions.

I have tried adding a registry key of: HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Common\Internet\OpenDocumentsReadWriteWhileBrowsing to '1' as suggessted here: spsstuff.blogspot.com/2006/07/office-2003-documents-open-in-read.html but that change did not work.

I have also attempted to locate a key of: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Office discussed in this article: www.tech-archive.net/Archive/SharePoint/microsoft.public.sharepoint.portalserver/2006-08/msg00458.html but it does not exist on my systems.

I'm not sure what other information I can provide to be helpful, but any help or tactical application of common sense would be GREATLY appreciated.

Improve this question
1
  • Quick update of common questions for those that care: All of the documents are valid Microsoft Office documents, .doc, .xls, .ppt, etc. I have 400 clients on my network spanning over 5 hardware platforms, IBM T61s and R61s, and Dell M4300s, M65s, and D830s. Amazingly enough, only the 3 models of Dells have this problem. They all use the same basic 'load' of software, and exist in the same OU in Active Directory.
    – HeavyObjectLifter
    Jul 11, 2009 at 8:02

2 Answers 2

Reset to default
4

As you're probably aware, when clicking on the file it is downloaded to the local machine and opened from the file system. Depending on how the document is opened from the browser and the client OS used, there are a few places that the file could be copied to and the user will need write access to these places.

If they simply open the file and don't check it out to their local drafts folder, it will be copied to:

  • C:\Users\_username_\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.MSO (Windows Vista)
  • C:\Documents and Settings\_username_\Local Settings\Temporary Internet Files\Content.MSO (Windows XP)

If they check out the file and choose the 'Use Local Drafts Folder' option, it will be copied to:

  • C:\Users\_username_\Documents\SharePoint Drafts (Windows Vista)
  • C:\Documents and Settings\_username_\My Documents\SharePoint Drafts (Windows XP)

Can you check that as the end user you are able to create files in these locations? You may need to drop to the command prompt for Temporary Internet Files and enter a command such as:

type Test>test.tmp

By the way, the OpenDocumentsReadWriteWhileBrowsing registry key should have no effect on a SharePoint site, according to KB 870853. Behaviour 'by design'.

Improve this answer
3

Ok, so here is the simple, yet not so obvious, solution.

I tried all suggestions, made sure that permissions existed for the user to all folders, etc.

We ran a script to completely remove the local security policy, rebooted the machine so the domain policies would reign supreme, and that fixed the problem.

We have no idea why these local policies were only causing problems on the Dells, nor could we find the specific rule or policy that was the 'one' culprit.

So thank you for the help Alex, but I don't even think that THIS should qualify as an answer.

Improve this answer
1
  • Nice find! What was the script you ran?
    – jimbo
    Jun 2, 2010 at 16:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .