Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am trying to enable users to connect to Excel files on a share on the server. The users have access to that share. Using Procmon, I detected that OleDB creates a temporary file in this location:

c:\users\temp.<DOMAIN>.00x

But the users do not have access to this folder by default and they receive the dreaded 'Unspecified Error' from OleDB. Supposedly, the issue can be alleviated by making the following change in the Web.config file:

<identity impersonate="true" />
to
<identity impersonate="false" />

However, this is a SharePoint server and thus I am unable to make that change without negatively affecting SharePoint. I would like to do one of the following to alleviate the issue that creates the extra temp files:

  • Automatically give users read and write permissions to new Temp directories, via a GPO, settings, or a script
  • Fix the server such that these temp directories are not created in the first place (this is preferred but from my searching seems much harder)

I am certainly willing to look at other solutions if you can recommend a better one. Also, I apologize in advance for my tremendous ignorance, I am not really a server admin. Thanks for looking!

share|improve this question
    
You mentioned both that this is a server share and that it's a SharePoint server. You also mentioned Excel. Where are the file(s) available, on a UNC share, DFS, or SharePoint? Also, the temp location specified is actually a temp profile being created or used. Which account owns and/or creates the temp file(s) in question? One more question: will multiple users connect to the Excel file at same time? If so, will they make changes? –  Lizz Mar 9 '13 at 6:31
    
The files are available on a UNC share of the server. Once an Excel file is dropped off in the share, it will only be accessed by an application. –  grizzljt Mar 11 '13 at 19:17
    
I think the user that created and owns the folder is the SharePoint Web App Pool account. –  grizzljt Mar 11 '13 at 19:23
add comment

1 Answer

Usually this happens because of a strange situation where the App Pool user creates temporary files used for editing, that the actual user does not have rights to access.

That is why when impersonation is set to false, the App Pool user identity is used and can access the file - but when impersonation is set to true, the user account is being used, which doesn't have access to those files.

Setting write permissions for everyone to the temporary file parent directory should resolve this issue. I suppose there are some separate security concerns there, but it does not seem to be an issue in your case (as you even suggested it).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.