Wednesday, January 22, 2014

'DisableLoopbackCheck' to fix - Error: Access is denied. Verify that either the Default Content Access Account has access to this repository .........


Error:
Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has "Full Read" permissions on the SharePoint Web Application being crawled.

Root Cause :
This issue occurs when the Web site uses Integrated Authentication and has a name that is mapped to the local loopback address.

This is because your operating system(Windows 2008 in my case) include a loopback check security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name.

Resolution:
Following instructions would disable the LoopBackRequest in registry. 

1. Run regedit.exe from the command prompt
2. In the registry editor navigate to "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa"
3. Right click on "Lsa" and create a new 32bit DWORD value called DisableLoopbackCheck
4. Right click  and Modify the value of "DisableLoopbackCheck" as "1"
6. Close the registry editor.

You may now restart the crawl and hopefully it will work.

Thursday, July 18, 2013

Microsoft.SharePoint.Administration.SPUsageImportJobDefinition.. An update conflict has occurred, and you must re-try this action. The object SPUsageServiceInstance was updated by....

To resolve this issue, clear the SharePoint Config Cache on all servers in the server farm. To do this, follow these steps:
  1. Stop the Timer service. To do this, follow these steps:
    1. Click Start, point to Administrative Tools, and then click Services.
    2. Right-click SharePoint 2010 Timer, and then click Stop.
    3. Close the Services console.
  2. On the computer that is running SharePoint 2010 and on which the Central Administration site is hosted, click Start, click Run, type explorer, and then press ENTER.
  3. In Windows Explorer, locate and then double-click the following folder:
    Drive:\ProgramData\Microsoft\SharePoint\Config\GUID
  4. Back up the Cache.ini file.
  5. Delete all the XML configuration files in the GUID folder. Do this so that you can verify that the GUID folder is replaced by new XML configuration files when the cache is rebuilt.

    Note When you empty the configuration cache in the GUID folder, make sure that you do not delete the GUID folder and the Cache.ini file
  6. Double-click the Cache.ini file.
  7. On the Edit menu, click Select All.
  8. On the Edit menu, click Delete.
  9. Type 1, and then click Save on the File menu.
  10. On the File menu, click Exit.
  11. Start the Timer service. To do this, follow these steps:
    1. Click Start, point to Administrative Tools, and then click Services.
    2. Right-click SharePoint 2010 Timer, and then click Start.
    3. Close the Services console.
    Note The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm.

Monday, April 15, 2013

One or more field types are not installed properly. Go to the list settings page to delete these fields.

This errors occurs when using CAML query with display names rather than internal names.

Solution is to use the internal name in the query. You can find out the internal names of the list columns using SharePoint Manager (http://spm.codeplex.com/releases/view/51438)

Happy coding!

Sunday, April 7, 2013

An update conflict has occured, you must re-try this action again.The object SPProcessIdentity was ...

Error :
An update conflict has occured, you must re-try this action again.The object SPProcessIdentity was ...
This error occurs when any timer job task is underway and it is preventing another task. For example when you are configuring service accounts I got this error.
The solution is to clear and reset the SharePoint timer job 'Cache' by doing following steps: 
  1. Stop the Windows SharePoint Services Timer service (Found in Windows Services)
  2. Navigate to the cache folder
    In Windows Server 2008, the configuration cache is in the following location:
    Drive:\ProgramData\Microsoft\SharePoint\Config
    In Windows Server 2003, the configuration cache is in the following location:
    Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config
    Locate the folder that has the file "Cache.ini"
    (Note: The Application Data folder may be hidden. To view the hidden folder, change the folder options as required)
  3. Back up the Cache.ini file.
  4. Delete all the XML configuration files in the GUID folder. Do this so that you can verify that the GUID folder is replaced by new XML configuration files when the cache is rebuilt.
  5. Note When you empty the configuration cache in the GUID folder, make sure that you do not delete the GUID folder and the Cache.ini file that is located in the GUID folder.
  6. Double-click the Cache.ini file.
  7. On the Edit menu, click Select All. On the Edit menu, click Delete. Type 1, and then click Save on the File menu. On the File menu, click Exit.
  8. Start the Windows SharePoint Services Timer service
  9. Note The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm.
  10. Make sure that the Cache.ini file in the GUID folder now contains its previous value. For example, make sure that the value of the Cache.ini file is not 1.

Move-SPUser : The parameterless Read method can only be used when this instance was initialized with an SPUser object.

Correct way of doing it-

$user = Get-SPUser -web http://my.website.url -Identity DomainA\UserA
Move-SPUser -IgnoreSID -Identity $user -NewAlias 'DomainB\UserA'

Saturday, March 16, 2013

Monday, February 18, 2013

PowerShell command to disable the loop-back check



When you use a custom host header to create web application in SharePoint and  browse it from a local machine that is running Microsoft Internet Information Services (IIS) 5.1 or a later version, you may receive an error message that resembles the following:

HTTP 401.1 - Unauthorized: Logon Failed


To resolve this issue execute the following PowerShell command to disable the loop-back check

New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -value "1" -PropertyType dword