The file exists. (Exception from HRESULT: 0x80070050): Adding users to SharePoint

Issue: When adding a user to the site we are getting error The file exists.

Error: The file exists. (Exception from HRESULT: 0x80070050)

Background: We had some users migrated from one domain to another and this is an issue with one of those users.

Site admin confirmed that user is migrated correctly and getting above error once adding user to the site.

Troubleshooting:

We tried to add the user from our side and we were also getting the issue.

Tried to add the user on another side and was having the issue.

Checked in Active directory if user had valid account created.

Checked in User profile if user account entry exists.

Able to find the user in People picker and working fine.

The moment we click Ok, we get the error message.

Tried to delete the user site using PowerShell and re-added him, did not help.

Resolution:

It seems to be an orphan entry of the user old account exist on the site

Started looking at content DB with SQL queries.

select s.Id, w.FullUrl from Sites s inner join Webs w on

s.RootWebId = w.Id

select * from UserInfo where tp_Login='domain\username' and

tp_SiteID=''

Deleted user entry form UserInfo table in SP content db.

delete from UserInfo where tp_Login= 'domain\login'

Create account again using standard SP actions or just login to portal using this account. It did helped to resolve the issue.  

Alternative approach can also be acquired to clear the user SID history.

http://blogs.technet.com/b/ashleymcglone/archive/2011/11/23/how-to-remove-sid-history-with-powershell.aspx

Applies to: SharePoint server 2010, Windows Server 2008.

IIS Admin Service service terminated with service-specific error 2148073478 (0x80090006): SharePoint Server 2010.

Issue: When we tried to open a SharePoint web app, we get error message Page cannot be displayed. 

Error: In event ID we have seen error message:

IIS Admin Service service terminated with service-specific error 2148073478 (0x80090006)

Background: We had seen event ID 6482 in one of SharePoint servers which is saying that SSL certificate on one of web application has expired. Though we had not used SSL in any of our SharePoint webapp, but still we were getting SSL error message.

MS had suggested to work based on the KB http://support.microsoft.com/kb/962928 and renew self SSL on the web application; however this didn’t resolve the issue.

MS had suggested to follow the steps in another KB http://support.microsoft.com/kb/908572 to give Local Administrator rights to admin account at location \Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA as Renew Self SSL were failing.

This did fix the issue of Event ID 6482 to fire in the event viewer but did lead to another issue which is point of discussion in this article.

We have seen after testing this fix what MS had suggested, it did break our testing and preproduction environment where were not able to start IIS service and getting the above error message.

Resolution:

To fix this issue and have IIS admin service running again was also challenging.

Based on one of steps to fix this issue MS has suggested to rename the MachineKeys folder at location \Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys based on the KB https://support.microsoft.com/kb/908572.

It did fixed the issue however, when testing servers were rebooted (as a part of patching) the IIS Metabase was corrupt resulting in IIS Admin service did not start and all web application were inaccessible.  

Anticipating this could result in serious issues to Production environment, we decided to take production servers out of patching schedule and re-opened the case with MS informing them the issue we are facing after the fix was implemented to resolve first problem.

We restored the old MachineKeys folder by renaming it to original name and deleted the newly created MachineKeys folder first in testing platforms.

During the testing in root to live we spotted that there were two services (Cryptographic Services and syslog-ng Agent Service) which were automatically creating the MachineKeys folder and was not letting us rename it.

Stopping these services allowed us to rename the MachineKeys folder and we were able to start IIS Admin and World Wide Web Publishing services in sys-test and Pre-production platforms.   

Implemented the same steps in production servers, rebooted each server one at a time to check if any issues occurred post fix.  

There was no disruption to the service and IIS web applications are working fine.   

Reference: http://blogs.msdn.com/b/saurabh_singh/archive/2007/08/02/iisadmin-startup-issues.aspx

Applies to: SharePoint server 2010 and Windows Server 2008, IIS 7.

Unable to run audit Reports- .XML file opens as blank page : SharePoint 2010.

Issue: Whenever a user clicks on a Audit report on his SharePoint site, it brings back a blank page.

Error: There is no error as such, however, audit log reports opens as blank page in any browser.

Background: We had started facing this issue when user has reported that the issue is happening on one site. We started investigating from that side only. However, when we had explored this is wider issue and affecting multiple sites.

This was not the end point this issue was affecting other platforms also.

This issue was reported on multiple sites where when running audit logs reports opens as a blank page.

This issue was initially reported for one of the site and then we checked on other sites it has the same behavior.

Troubleshooting:

As an initial investigation checked by disabling AV scan on our testing servers and Production severs but it came as clear.  

As this issue was wide, to isolate it concentrated on one test environment where one server was working and other was not!

Compared,

• IE settings on servers, clearing cache and resetting IE settings did not work.
• IIS settings on both server and they were intact.
• Settings on compat.browser file, which controls the behaviour of the IIS web applications when requested over http in IE at location D:\IISWebSites\wss\VirtualDirectories\\App_Browsers\compat.browser.
• /_layouts/RunReport.aspx file content and no difference found.
• Web.config files and \12 hive folder settings, no difference found.

Have tried to trace the behaviour of the request via Fiddler and nothing found.

Compared to open the pages in different browser, IE, Chrome and Firefox.

It looked liked to be an issue with the way .xml file is parsed from IE.

Resolution:

Opened a case with MS and they had asked to confirm if http://support.microsoft.com/kb/2894844 orhttp://support2.microsoft.com/kb/2905247 KB is installed on any of the servers.

There were no entries of this KB on any of the servers.

Started comparing the Microsoft .NET Framework 2.0 Service Pack 2 updated on both of the servers. Assuming the issue has started in June, 14 month, started looking at the updates installed after May, 14.

On one test server (working one), last update ran on 31st Jan, 14, however on server non-working, last update ran on 16 May, 14 and the KB number installed was KB2894843 and we had KB2972214 installed on 12 Sept, 14.

Thinking and agreeing with MS eng. that KB2972214 installed on 12 Sept, 14  must had not caused the issue because the issue was there before 12 Sept, 14.

Targeted the KB2894843 installed on 16 May, 14 and uninstalled it from the server non-working sever.

Tried to browse the Audit log and it did work fine.

Note: This KB is near in the number, where MS has asked to check if any of the

http://support.microsoft.com/kb/2894844 or http://support2.microsoft.com/kb/2905247, we had installed on the servers and answer was no.

Installed KB2894843 on the working server and it did break the audit logs and started coming as blank page.

Uninstalling the KB2894843 again from working server, had fixed the issue again.

With these entire tests we confirmed that http://support.microsoft.com/kb/2894843 had created the issue.

MS has confirmed that this is recent issue they were reported with by other clients as well and root cause of the issue is still un-known.

They had requested if we can uninstall the KB from all the affected servers as they have no plans to introduce any Hot-fix for this KB in near future.  

Applies to: SharePoint Server 2010, Windows 2003 Server, .Net Frame Work 2.0.