I have a single SharePoint 2007 server hosting several SP sites - one internal intranet site; the rest are accessible across the Internet. I have users reporting that on occasion they are unable to edit the Notes or Description section of a new calendar or news entry on all of our SharePoint sites. This does not happen every time someone attempts to post an entry. In fact, it happens at about a rate of 25% or less. I wondered if there was a permissions issue with our users. In every case, when this happens the users have anywhere from Contribute to Full Control access for the site they are attempting to write to. I see nothing in any log file as to what may be causing this problem nor have I been able to recreate the problem myself on my PC. While it is not brought use of our SP site to a standstill it is an annoyance that I need to make go away especially since some of our clients do use the external sites across the Internet. Anyone with any thoughts or assistance on what may be going on here is welcomed. I have screen shots of what this looks like when it happens to a user but I do not see a way to post them here. I can send them to anyone who may be able to help after seeing them. TIA

Great. If they can access the items and make the changes on another persons' computer, check the profile settings on the users client machine. Ask IT for help. This same issue came up at the MN SharePoint User Group meeting several months back. The conclusion was changes to the profile settings on the client machine. My favorite part about this issues is that we are unable to repeat the error when we try. :( Good luck.Tamara Bredemus SharePoint Minion...working up to Maven

What within the profile are we looking for?

Hello Cuncabo, In intermittent access denied cases like this, we have seen the following changes to the web.config file resolve the behavior. (Be sure to back-up your web.config before making any changes!) Edit the web.config for the effected web application with the following value: <identity impersonate="true" /> - CHANGE TO: <identity impersonate="false" /> If you would like to perform an additional test before making the web.config change, you can add a user who experiences the problem to the local administrators group on the server temporarily, to verify they no longer experience the error. If this alleviates the behavior, it is very probable that the web.config change will be successful as well. Please advise as to the status after the above changes. Sincerely,

Hi Cuncabo, It's the web.config for the application having the problem. You can take a copy of that web.config before you make any changes to it (which, in my experience, is always a good idea to have). Assuming you've done so, are you still seeing this issue? Thanks, Tracy