SharePoint Error for One User - The File Exists

Today had an interesting support issue to investigate. Of all the users on a SharePoint intranet, one person was unable to upload documents - each attempt to upload a document to a document library resulted in the "Access Denied" page. And the ULS log revealed little of value even in verbose mode.

The other strange thing was that this user is configured as the site collection owner, and was able to create document libraries fine. But then could not add a document to the document library he had just created!

Finally got some clues when I removed that account from the site owner SharePoint group (just in case that group was causing the behaviour). When I tried to add the account back to that group, an error page displayed with the useful(?) message "The file exists (Exception from HRESULT: 0x80070050)". At least that helped to confirm that the issue was in the user account.

A bit of research revealed this post on the subject - seems likely that the SID for the account has changed at some point. The described fix is to modify the SID in one of the SharePoint database tables. That's a bit of a worry, given that fiddling with the database content is like confusing a Kiwi accent for an Australian - to be avoided. But it may be the only approach available. Let me know if you try it out and it works for ya.

Roadblocks in the Install of Server 2008 R2 and SharePoint 2010 Beta

First up in my path to getting SharePoint 2010 running in a Hyper-V VM was the case of the missing roles in Windows Server 2008 R2, caused by a Windows update that failed to install.

For some unpleasant reason, KB971468 had failed to install correctly, following the cancellation of the install of KB890830 (the windows update panel had stopped mid-install, and the progress bar just stayed where it was). The outcome of this was that no roles displayed in the Server Manager - instead just an error message.

With the help of some worried searching, I came across this article by Glafkos Charalambous explaining the fix - use the System Update Readiness Tool from Microsoft to discover the faulty update files, then manually extract those files from the relevant update packages and copy them to the updates folder.

Once I had replaced the bad MUM files (wonder if there are DAD files anywhere in the system, too??), then I couls rerun the other updates that were marked as failed in the Windows Update History.

Hey, honey, I got my roles back!