How to Fix “The file exists. (Exception from HRESULT: 0x80070050)…” error on SharePoint

If you're getting the error "The file exists. (Exception from HRESULT: 0x80070050)", when you attempt to access your SharePoint site, or even SharePoint Central Administration site, the chances are that some (or all) SIDs on your server were changed. This has probably happened because you have removed and recreated some user accounts that you use to run SharePoint services, or you have run sysprep on your server, or you have recently turned your SharePoint server into Active Directory domain controller. It's not a good idea to do any of those things with your SharePoint server, but I'm not here to judge – I'm here to help J

Please note, that the steps described below is a "low-tech" solution to the problem, which requires you to actually understand what you're about to do. USE AT YOUR OWN RISK!!! And, of course, do not forget about backups, backups, backups. Also, I would like to point out the credit for this solution goes to the blog and his/her author that is no longer online.

Anyway, to solve "The file exists. (Exception from HRESULT: 0x80070050)…" error:

  1. Login to your SharePoint and open SQL Server Management Studio. Create New Query
  2. To get the list of Site IDs you need to use SharePoint_AdminContent_* database for Central Administration Site and run the following query:
    SELECT s.Id, w.FullUrl FROM Sites s inner join Webs w on s.RootWebId = w.Id
  3. As a result of the query above, you will see all Site IDs for the selected database. Now, using that data, run a new query:
    SELECT * FROM UserInfo WHERE tp_Login='Hostname/Username' and tp_SiteID='XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'
    where tp_Login is the hostname and username using which you're trying to login to SharePoint; and tp_SiteID is the site ID from the previous query
  4. As a result of the query above, you will see the SID for the selected user. Now, here comes the tricky part, you need to get SID number for the user account that you're logging in with (in my case, it was Administrator account) and convert it to hexadecimal format:
    1. To get SID for a user account, you can use PSTOOLS utility. Run PSGETSID \\HOSTNAME USERNAME to get SID info
    2. To convert the SID to hexadecimal format, use the following VB script and run it against the SID obtained in the previous step: sid2gex.vbs mySID, where my mySID is the SID for the user account you're working with. As a result, you will receive SID in the hexadecimal format.
  5. Now we will update our database table with newly obtained SID using:
    UPDATE UserInfo SET tp_SystemID = 0x010500000000000000000986BD9EA976E44036C3F5D3F04040000
    FROM UserInfo
    tp_Login='hostname\username' and tp_SiteID = 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'
    where tp_ID, tp_guid, tp_Login and tp_SiteID are the attributes of the user account for which we want to update tp_SystemID. Note: you might have to repeat those steps for the services accounts which are running your search, shared services provider, etc.

After implementing the steps above, you might have to update service accounts in the SharePoint configuration. Microsoft has an excellent guide on how to make those changes.

SharePoint and Vista: a problem with “Explorer View” and “Create list from spreadsheet”

We have recently encountered a problem with some of the SharePoint (WSS or MOSS) features not working properly in Windows Vista:

  • When users attempt to display a document library in the Explorer view within the web application that uses Kerberos authentication, nothing happens: Explorer view never comes up and no errors displayed either
  • Or, when users attempt to display a document library within the web application that uses NTLM authentication, they get "Your client does not support opening this list with Windows Explorer" error;
  • When users attempt to create list from Excel spreadsheet they get "Method 'Post' of object 'IOWSPostData' failed" error

After a lot of research and many unsuccessful attempts to fix these problems using various solutions found on the web, I have finally able to find a workaround that have worked on Windows Vista 32-bit.

Solutions that did not work in our situation:

  • Installing and enabling WebDav on IIS 7
  • Installing Desktop Experience on Windows 2008 server 64 bit
  • Modifying EXPTOOWS.XLA macro file to force using a different version number
  • Etc…

The workaround that worked:

  • Install hotfix KB945015 on the client machine to fix a bug caused by an extra forward slash mark (/)appended to the query path of a WebDAV PROPFIND request
  • Install Web folder hotfix on the client machine to get Vista map a drive to a web location on SharePoint
  • Map a "Web Network Location" on your PC to the root of the SharePoint site in question and ensure that you save the credentials

This workaround only worked for Windows Vista 32-bit.

Related resources:

Implementing Kerberos for SharePoint running on Windows Server 2008 and IIS7

Before I start writing how to set up Kerberos authentication in SharePoint, let me explain our set up a little bit, i.e. server names, account names and so on that will be used in this guide:

WSSSERVER1 – SharePoint web front server

WSSSERVER2 – another web front server (optional)

DBSERVER1 – database server running Microsoft SQL Server 2005 SP2

Domain\wss_srvc_account – User account used to run SharePoint services

Domain\sql_srvc_account – User account used to run SQL services on database server

Domain\wss_apppool – User account used to run SharePoint web application pool

Domain\mysite_apppool – User account used to run My Site web application pool

Domain\sspadmin_apppool – User account used to run Shared Services Provider web application pool


To set up a Kerberos authentication in SharePoint (WSS or MOSS) you need to do a bunch of small configuration changes:

  1. Make sure that you have host headers set up for your SharePoint sites. For example, in case of Windows SharePoint Services you will have only the main SharePoint website, whereas in case of Microsoft Office SharePoint Server 2007 you will have main SharePoint website, My Site website, and Shared Services Provider Sites. For the sake of simplicity, let's call those host headers: http://sharepoint, http://mysite, http://sspadmin respectively.
  2. Update Alternate Access Mappings to point websites to website host headers. In other words, replace http://servername:2222 entry with http://sharepoint


  3. Add SPN records for:
    1. Hostnames and FQDN of computer account(s) of your SharePoint server(s), for example
      Setspn.exe -A HTTP/WSSSERVER1 DOMAIN\wss_ srvc_account
      Setspn.exe -A HTTP/WSSSERVER1.domain.local DOMAIN\wss_srvc_account
      Setspn.exe -A HTTP/WSSSERVER2 DOMAIN\wss_ srvc_account
      Setspn.exe -A HTTP/WSSSERVER2.domain.local DOMAIN\wss_srvc_account
    2. Hostnames and FQDN of computer account of your SQL server, for example
      Setspn.exe -A MSSQLSvc /DBSERVER1:1433 DOMAIN\sql_srvc_account
      Setspn.exe -A MSSQLSvc /DBSERVER1.domain.local:1433 DOMAIN\ sql_srvc_account
    3. Host headers for your SharePoint websites, for example
      Setspn.exe -A HTTP/INTRANET DOMAIN\wss_apppool
      Setspn.exe -A HTTP/ INTRANET. domain.local DOMAIN\wss_apppool
      Setspn.exe -A HTTP/MYSITE DOMAIN\mysite_apppool
      (Do not apply in case of WSS)
      Setspn.exe -A HTTP/MYSITE. domain.local DOMAIN\mysite_apppool
      (Do not apply in case of WSS)
      Setspn.exe -A HTTP/SSPADMIN DOMAIN\sspadmin_apppool
      (Do not apply in case of WSS)
      Setspn.exe -A HTTP/SSPADMIN. domain.local DOMAIN\sspadmin_apppool
      (Do not apply in case of WSS)


    1. Configure "Trust for Delegation" on all computer accounts and user accounts used in SharePoint configuration. To configure "Trust for delegation":
      1. Open Active Directory Users and Computers management console
      2. Right click on a user or computer account that require ""Trust for Delegation" configured and click on Properties
      3. Where you find this option in the GUI depends on the Active Directory functional level. In case of Windows 2000 domain, the option is under Account tab for user accounts and General tab for computer accounts. In case of Windows 2003 domain, the option is under a separate Delegation tab. Note: Delegation tab is only visible for accounts that have SPNs registered


  4. Configure Component Services to allow Local Launch and Activation permissions for IIS WAMREG Admin Service for all application pool accounts used in SharePoint configuration. To configure Component Services setting go Control Panel >> Component Services >> Computers >> My Computer >> DCOM Config >> properties of the "IIS WAMReg Admin Service" >> Security tab >> edit "Launch and Activate Permissions" >> add "Local Launch" and "Local Activation" permissions for all the application pool accounts


  5. Because in IIS7 HTTP.sys is handling the authentication, it is by default done under the LocalSystem account regardless of the application pool account you're using. However, because even a single SharePoint server configuration is now considered a web farm, we should use a domain account to run SharePoint application pools. As a result we need to modify applicationhost.config file to configure the useAppPoolCredentials attribute in system.webServer/security/authentication/Windows-Authentication configuration section to true.

    <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true"/>



  6. Once you have made a change to applicationhost.config file you might start getting errors 6398, 7076, 6482 in your Event Viewer. To get rid of those errors you need to apply hotfix KB946517. This hotfix is currently is available for Windows Server 2003, XP and Vista and it is under development for Windows Server 2008. I have used Vista version of the hotfix on Windows Server 2008 and it seems to have worked fine (knocking on wood...)


  7. Now you're ready to switch your SharePoint web applications to Kerberos authentication. Open SharePoint Central Administration >> Application Management >> Authentication Providers >> choose your web application >> change authentication to Negotiate (Kerberos)



  8. In case of MOSS, to change your Shared Services Provider web application to use Kerberos authentication run the command: stsadm.exe -o SetSharedWebServiceAuthn –negotiate. Stsadm.exe is usually placed under C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin.



That's it, you should now have your web applications using more secure Kerberos authentication. You can use Fiddler ( to verify that your web application is in fact using Kerberos authentication. Here are a few links that will help you might find useful:

Related resources:

Enabling anonymous access on MOSS 2007 / WSS 3.0 web applications

To enable anonymous access for a web application within SharePoint:

1. Go to Central Administration >> Application Management >> Authentication Providers.

  • make sure to pick correct web application from the drop-down list at the top-right corner of the page.
  • select the Membership Provider (most likely it will be "Default") and enable check "Enable anonymous access" checkbox.
  • click OK to save the settings.

2. The step above will usually enable anonymous access in IIS Manager, but just be sure:

  • open IIS Manager
  • right-click on your website and click on "Edit" under Authentication and Access Control
  • make sure "Enable anonymous access" is checked

3. We now need to explicitly enable anonymous access on our website(s)

  • browse to the website
  • click Site Actions >> Site Settings >> People and Groups >> Site Permissions
  • click on Settings >Anonymous Access and enable anonymous access for the site

* Anonymous access will be also enabled on all subsites that inherit security settings from the parent site.

Related resources:

Installing SQL Server 2005 on Windows Vista or Windows 2008: IIS 7.0 problem

Recently I tried to install SQL Server 2005 on Windows Vista and I have received a warning message for IIS Feature requirement on the System Configuration Check page of the SQL Server 2005 Setup program. This means that you won’t be able to install SQL Server components, requiring IIS, such as Reporting Services. The problems occurs because IIS 7.0 is much more customizable and has much more components, so some of the components required for RS installation are missing from the default IIS 7.0 install. Here is the list of the IIS components required for Reporting Services:



Static Content

Common HTTP Features

Default Document

Common HTTP Features

HTTP Redirection

Common HTTP Features

Directory Browsing

Common HTTP Features


Application Development

ISAPI Extension

Application Development

ISAPI Filters

Application Development

Windows Authentication


IIS Metabase

Management Tools


Management Tools


For instructions on how to install missing IIS components in Windows Vista, go to: (

For instructions on how to install missing IIS components in a Server Core installation of Windows Server 2008, go to:

The solution is also explained in Microsoft KB920201.


Uploading large files to TFS

We used to get a timeout error every time we tried to upload files larger than 48Kb to TFS. The timeout error was caused by one of numerous IIS hidden settings, i.e. UploadReadAheadSize parameter in IIS. Because this parameter is not set by default, IIS uses the default schema value of 48Kb. 

To allow larger files to be uploaded to TFS, we had to change this parameter to a larger value (in our case I've set it to 10Mb). Here is how it's done:

  1. Open Command Prompt
  2. Go to your Inetpub\adminscripts folder
  3. Type in adsutil get w3svc/UploadReadAheadSize to check your current setting
  4. To change this parameter, type in adsutil set w3svc/UploadReadAheadSize SIZE_IN_BYTES. For example to set this parameter to 10Mb use "10000000" as the size
  5. Type in adsutil get w3svc/UploadReadAheadSize again to make sure that the parameter has been changed